Develop Reference

Cookies are not stored in android Webview API 21 and up

Background:
I am experiencing a very confusing behaviour with android Webviews in API 21 and up when testing in real devices.
I have a local HTML5 application (inside assets folder) with the following functionality
Login (2 steps authentication).
Show a list of items depending on the authentication.
The problem:
After doing the login requests, the server returns a cookie with the session. This cookie is not stored in the Webview when using real devices with API 21 or up. If I use emulators (Genymotion in this case), the cookies are properly stored.
More information:
The request to do the auth has the following headers:
POST http://myServer/j_spring_security_check HTTP/1.1
Proxy-Connection: keep-alive
Content-Length: 101
access-control-allow-origin: *
accept: application/json
access-control-allow-credentials: true
User-Agent: Framework/1.5.0 (Linux; U; Android 6.0.1; Nexus 5X Build/MMB29Q) App/0.1.1
Origin: file://
content-type: application/x-www-form-urlencoded
Accept-Language: en-US
X-Requested-With: app.package
Host: myServer
With the following response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=4D169E8656DBEDFFA4D17FE8D436A5BA; Expires=Fri, 19-Feb-2016 14:27:55 GMT; Path=/; HttpOnly
Content-Type: application/json;charset=UTF-8
Content-Length: 43
Date: Fri, 19 Feb 2016 14:17:55 GMT
The cookie is not stored in devices with API 21 or more. Same request/response works fine in the rest of devices + all the emulators
Clarification:
This flags are enabled inside the app:
android.webkit.CookieManager.setAcceptFileSchemeCookies(true);
(Before CookieManager or webview is instantiated, as documentation says)
if(VERSION.SDK_INT >= 21) {
CookieManager.getInstance().setAcceptThirdPartyCookies(this.nativeWebView, true);
}
If after doing the authentication, I access the cookies datastore and
check the "hasCookies" method, I get false.
The two step auth service actually calls 3 different paths from the same endpoints. None of the cookies that the response that generate this services are stored. I don't know if this is relevant or not.
When doing simple authentication (to a different server), cookies are stored properly in all the devices emulators.
I am using Angular 1.5
I am aware that the service is using http instead of https. That will be solved in the future.
I get no error message in the consoles.
Questions:
Is there any internal security measure in the webviews that blocks the storage of the cookies? Why does it work on emulators (that are rooted devices) and not in real devices? This really bugs me.

If the network request is done using window.fetch you may need to add:
fetch('/something', { credentials: 'same-origin' }) // or 'include'
On chromium, window.fetch has the credentials flag set by default to 'omit' and no cookies are stored into the cookie storage. More details of this bug here: https://bugs.chromium.org/p/chromium/issues/detail?id=477523

Authentication with oauth2 on soundcloud api

I'm trying to get logged in soundcloud by using their API. I manage to got a code with a success response from /connect but when I try to get a token, I end up with a 401 error. Here is what I send :
POST /oauth2/token HTTP/1.1
Host: api.soundcloud.com
Content-Type: application/x-form-urlencoded
Cache-Control: no-cache
Postman-Token: 255c7769-0f65-5c40-27bc-9429ea8c38ea
client_id=<my client id>&
client_secret=<my secret id>&
redirect_uri=http%3A%2F%2Fmywebsite&
grant_type=authorization_code&
code=a99cfc85c0e46235d7fdb9ca74b7dddd%23
Does anyone knows what I miss here to get a working request ?

It turned out I was not calling /connect correctly, this is the correct way :
https://soundcloud.com/connect?
client_id=<my client id>
&redirect_uri=<my redirect url>
&response_type=token
&scope=non-expiring
&display=popup
With response_type=token, we directly receive an access token so we don't need to call /oauth2/token then.

Android built-in browser and download

This is driving me nuts. I want to offer an .apk file for download. All browsers I've tested will download my file without any problem. Except for the built-in browser in android. For some strange reason it will repeat the request for the resource. Using BurpSuite I've discovered that the apk file is transferred flawlessly. I proxy the file, but I send the headers right away, using curl I could confirm the headers are sent and the content starts being transmitted in the following. I've compared my headers with the headers sent by threema.ch which works flawlessly.
These headers are sent by my application:
HTTP/1.1 200 OK
Date: Sat, 16 Aug 2014 16:41:01 GMT
Server: Apache/2.4.7
Content-Disposition: attachment; filename="test.apk"
Content-Type: application/vnd.android.package-archive
Transfer-Encoding: Chunked
These headers are sent by Threema:
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 16 Aug 2014 17:49:10 GMT
Content-Type: application/vnd.android.package-archive
Content-Length: 14146751
Connection: keep-alive
Content-Disposition: attachment; filename="Threema-1.63.apk"
Strict-Transport-Security: max-age=31536000; includeSubdomains
I've first loaded the file through an iframe. Currently I'm redirecting the browser to the download using HTTP redirect. I offer the file from a different subdomain. But I also tried delivering the file from the same domain and using a html link.
These are the headers sent by the client. First:
GET /download/download/NlnMhaeXmcjSosfqRTcG8YdxQgQGSxTWQeE10-GrH4U HTTP/1.1
Host: l.dl.test
Proxy-Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Linux; Android 4.4.4; Nexus 7 Build/KTU84P) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/33.0.0.0 Safari/537.36
Referer: http://l.google/device/deviceid/351cd7c24f637eb5?token=6Xf3nJIIMIa4toKrpTqgDGFjAKzeBBoaeduMmcIMeGY
Accept-Encoding: gzip,deflate
Accept-Language: de-DE,en-US;q=0.8
X-Requested-With: com.android.browser
And then (around 20s later):
GET /download/download/NlnMhaeXmcjSosfqRTcG8YdxQgQGSxTWQeE10-GrH4U HTTP/1.1
User-Agent: Mozilla/5.0 (Linux; Android 4.4.4; Nexus 7 Build/KTU84P) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/33.0.0.0 Safari/537.36
Referer:
cookie:
Accept-Encoding: identity
Host: l.dl.test
Connection: Keep-Alive
I'm generating a download id for one time use. The second Request will fail, because the id becomes invalid after the first request. The download works if I permit the second attempt to download the file.
Might it be that the android browser wants compressed content in the first attempt and if it gets identity content it will make a second attempt using Accept-Encoding identity? I also tried setting Content-Encoding: identity without luck.
Workaround:
The only way I've got this working without sending the .apk twice is using this very stupid (and properly error-prone) workaround:
header("Content-Disposition: attachment; filename=\"test.apk\"");
header('Content-Type: application/vnd.android.package-archive');
// Ugly workaround for bug in built-in android browser.
if (
isset($_SERVER['HTTP_X_REQUESTED_WITH'])
&& ($_SERVER['HTTP_X_REQUESTED_WITH'] == 'com.android.browser')
&& isset($_SERVER['HTTP_ACCEPT_ENCODING'])
&& (strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'identity') === FALSE)
) {
// The built-in android browser will make two requests for the apk
// file, one with Accept-Encoding gzip and deflate and one with
// Accept-Encoding identity. But it will only serve the second request
// with Accept encoding identity. So stop the first request.
// If the first request is shown, the workaround didn't work.
die ("Oh no! I'm sorry. The built-in android browser has a nasty bug."
. " It's hard to work around. If you see this the workaround failed."
. " Please try downloading with a different browser.");
}

Yahoo messenger API - error when open a long-lived connection for Comet-style notification

I'm trying to get Yahoo messenger notifications (comet style) to work on my Android app but I got a problem:
I have all the oauth tokens + IM cookie, I make the call to notify server but it responds with
403 Bad IM cookie or URI credential
The IM cookie which is sent is correct because it is the same as the one I got from POST /session.
The call:
POST to:http://rproxy2.messenger.yahooapis.com/v1/pushchannel/user_id?sid=T3qRkifs3BiGXCW4LOSoThi3lG2HvWNagr.mGA--&rand=-1131022177&count=10&seq=1&format=json&IM=2x5A0IOr9Js_8er8BgSYUCB9fjB.d20FbKds7NdJdkzWK4u2A92k5dMrM72OetLz9.q70NQCwZpAqafQ5.XM-|QTvOT1rY3ukBC8o4Z0zeRg--&oauth_consumer_key=dj0yJmk9cFNKb2NKbTdINEtFJmQ9WVdrOVpHMW1aVXhKTjJNbWNHbzlNamcyTnpNMU1UWXkmcz1jb25zdW1lcnNlY3JldCZ4PWJh&oauth_nonce=939bc51c9a594c7cbf903643bc10f7d1&oauth_signature_method=PLAINTEXT&oauth_timestamp=1328108171163&oauth_token=A%3DosG_yqL.hxped9sV4ZMVD2A5vugclvEOSKIw85DOg17vQa8N1jQK6UcGqeLGLXKFalrxnYA_iA_ArmhbN6oJ_CEINGwiq7MWsVjO_vQT5bwhmcBMwBLByhusduuH2BFJw1Zd2w_uDj5fEUVMK9bMDzg.fYEpdm1uK.OgwyYLPCwdkzW0w6ujPpaFAea7gwmsSBYHECzjXm8wduoe1Sw3rpJH4z9PGIe8Hkt3wrbyJpW9BuiU4g6OyE1f8nhzHVkcG_70KQiIR_oV3tP8_l4SCsbbHMvSzlyZjK1V6gJp0Q94fAcfuIWQ1Vd.iD.UZPEyzdzYK.k5Q6pE4H3At8czcXFOpmOL5eUwfbeQEtXePCL1b2v9oY4BxtH_dCUVTMhzQsV.YpKZV.ZRZzK8ThveL5gfGuqYcBZLHwVilQnQWo477XwT10GbvWUzJ2EH4v5m9q.sGMViSIKWjbE2O6YfwhYXAgQMA3d8wQLL7IoY4QC0.IR4T8M_KnZVlKoi_EiED8VuK9h7h3emBZeXoM15rqGk2..HUJQEuIe1d0YbTPEGKdM.fbCcT7_Y0Szzw3abf9b1Xjzm8VkNSKL.LXAmy8c9PyNatUT_hKFmzmWMd1RRYfd8rF7i6i7Ec_cVv06QhwCQyKlEsCQh7UChUe9JykUmiA6JOm4JOpsbTQWS1Iec35zrltc4YwouUlMx.y6JbzB_VYL9jkzeuu&oauth_version=1.0&oauth_signature=2cd720831677df11508571218aed6c36c9cf2b51%26e57b0e111092b000a43b4ae9c928178fd5da4b9f
connection: keep-alive
cookie: IM=2x5A0IOr9Js_8er8BgSYUCB9fjB.d20FbKds7NdJdkzWK4u2A92k5dMrM72OetLz9.q70NQCwZpAqafQ5.XM-|QTvOT1rY3ukBC8o4Z0zeRg--
User-Agent: Dalvik/1.2.0 (Linux; U; Android 2.2; sdk Build/FRF91)
Host: rproxy2.messenger.yahooapis.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
The server responds with:
HTTP/1.1 403 bad IM cookie or URI credentials
Connection: close
I followed all the instrunctions from docs, not sure how can make it to work.
Thanks.

Your HTTP POST is empty (Content-Length: 0), the docs state:
Note: even though all inputs are optional, the server
still expects an empty POST body (JSON: "{}")
so, change your Content-Type to "application/json;charset=utf-8" and include
{}
as the body of the HTTP POST.

Long lived connections need to be GET calls; see "Notification Management (Comet-Style Push) API", here.

Android WebView-based browsers not able to access protected resources through Oracle Access Manager (OAM)

We have a website that makes use of OAM for single sign on (form-based authentication). When we submit credentials to WebGate / Access Server the authorization succeeds, however after the authentication is performed, the form action (as configured in the Authentication Scheme - with passthrough:no) returns a server error instead of redirecting to the originally requested URL.
If we use Mini Opera, we are able to get authenticated and forwarded properly.
This problem happens on numerous Android phones (versions ranging from 1.5-2.2), as well as the Emulator provided with the SDK.
This is proving to be a real problem as the default browser on Android phones is not able to get access to our sites(and this is the only browser that is having this problem).
I have created a WebView-based custom browser with the hope of seeing a client-side error and tried trapping every possible error....none show up....
I have tried to trace all of the http requests and found only a single difference in the requests... the http header for Connection:keep-alive is not sent by the Android WebView.
I have provided some tracing info below...
Has anyone run into this problem? Has anyone solved this?
Any insight to this issue would be greatly appreciated.
Thanks,
Tim
Request RAW Data-
POST
http: // MYSERVER/security/ATLAFunction HTTP/1.1 Host: MYSERVER:7777
Accept-Encoding: gzip
Accept-Language: en-US
Cookie:ObSSOCookie=loggedoutcontinue
Accept-Charset: utf-8, iso-8859-1,utf-16, ;q=0.7
Referer:http://10.84.32.71:7777/tpf/login.html
User-Agent: Mozilla/5.0 (Linux; U; Android 2.2; en-us; sdk Build/FRF42) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
Origin: http: // MYSERVER
Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,/*;q=0.5
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
uname=auser&pwd=appas
Raw Response Data -
HTTP/1.1 503 Service Temporarily
Unavailable Date: Tue, 05 Oct
2010 14:26:12 GMT Set-Cookie:
ObSSOCookie=II%2F4n5pFreT6B6hOAumv6pI6CZh6l04VhyXHrCzuRUT5hDEHMK%2FJCX659uyCkxgIyJ8ywB3BKrHxorsCwZwivpn91t9Mu%2FCKT7PrY23S518xoBeOam26tr%2B0pSfCbo%2FZXLmFIxjHFOPHPGxi5tHrOlUroXXA9Fe0GZz3SbJLMgAkCw0euuAVewOHKIjoDh8MwAdGtL4lo%2BmHhk5kB316iFJ4Aljr7cQYpAp1r%2BVGD9FbLkYl4ekY5hrlNfwYS%2BVjnR0uSIFjc0toiKkGN33z7%2FiElh2Ue2iWQrpCRcgFpxE%3D;
httponly; path=/; Cache-Control:
no-cache Pragma: no-cache
Content-Length: 312 Connection:
close Content-Type: text/html;
charset=iso-8859-1
<!DOCTYPE HTML PUBLIC
"-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>503 Service Temporarily
Unavailable</title>
</head><body>
<h1>Service Temporarily
Unavailable</h1>
<p>Sorry!The server is
currently unable to handle the
request due to a temporary
overloading or maintenance of the
server.</p>
</body></html>