Develop Reference

Why is a SameSite=Strict cookie for http://127.0.0.1:12345/ not being sent in Android browsers?

We have a cross-platform app that runs a web server on 127.0.0.1, on a randomised port. The server code is the same on each platform.
An example URL: http://127.0.0.1:12345/
To authenticate requests, a session cookie is set on the initial response. That cookie has HttpOnly and SameSite=Strict set, to improve security.
Just this week we have found that in current versions of most Android browsers (Chrome 109.0.5414.85, Chrome Beta 110.0.5481.40, Firefox 109.1.1, Edge 109.0.1518.53), authentication is failing. With the Chrome dev tools, I can see that the cookie is not being sent in requests, although it is in the cookie store. If I manually change SameSite=Strict to SameSite=Lax (undesirable) using the dev tools, the cookie is sent, and everything starts working normally.
Opera (73.1.3844.69816) is not affected, and neither was Chrome before it was upgraded on the test tablet (possibly a pre-100 version). I have not been able to find any relevant recent changes in Chrome.
The puzzling part is, this problem doesn't exist on Windows or iOS (Mac not tested yet); there is no problem using the app on Windows under the 109.x versions of Chrome, Firefox, and Edge.
If it was a browser policy issue (despite this being a same-origin request), I would expect it to carry across platforms. If it was a browser bug, I wouldn't expect both Chrome and Firefox to be affected.
What am I missing?

We still don't know the reason for the problem, but a work-around is to change the initial response (the one that sets the session cookie) from a 302 redirect to a 200 response with a <meta http-equiv="refresh"> tag (as described in this answer).
Other things that we tried, without success:
Use http://localhost or http://localhost.localdomain instead of http://127.0.0.1
Set the Secure attribute on the cookie
Set Location on the 302 response to an absolute URL (http://127.0.0.1:12345/) instead of just the path
Clearing browser cache and cookies
Set Cache-Control: private, no-store, must-revalidate on the 302 response
With the redirect, the Chrome dev tools showed this message about the session cookie:
This cookie was blocked because it had the "SameSite=Strict" attribute and the request was made from a different site. This includes top-level navigation requests initiated by other sites.
Some bugs and commits that may be relevant:
1221316 - SameSite context type should consider redirect chain - chromium
This is still behind a disabled-by-default feature flag: SameSite cookies: Hide cross-site redirect chain check behind a Feature. It can be enabled using the --enable-experimental-cookie-features command-line argument. Doing that on Windows made no difference to behaviour.
150066 - Set-cookie ignored for HTTP response with status 302 - chromium (closed wontfix)
696204 - Cookies are ignored on 302 redirects - chromium (closed wontfix)
This comment talks about setting the Cache-Control header on the redirect to prevent the browser caching the response. The rest of the discussion seems to be about an unreliably-reproducible problem.
Change cookie domain handling for IP address host

Django 1.9 is not setting the sessionid cookie on login response only on Android with Cordova 6.0.0

Our Android users have started complaining that every time they kill our app, they have to log in again. I am able to reproduce this on our Android devices, but not our iOS devices, not through our mobile website on any device, and not through our desktop website.
When I attach the Chrome debugger to our Cordova app running on Android, it looks like Django is failing to set the sessionid cookie on the login response path. On every other platform (including straight Chrome on Android) when I look at the response for that endpoint, the sessionid cookie is there.
Here is what the normal login response looks like in every browser other than Cordova Android. Notice the setting of the sessionid cookie:
Response Headers
Connection:keep-alive
Content-Encoding:gzip
Content-Length:654
Content-Type:application/json; charset=utf-8
Date:Sat, 23 Apr 2016 22:33:44 GMT
ETag:"11186a50be09093d01d4e82ff4d9d3e5;gzip"
Server:nginx/1.8.1
Set-Cookie:sessionid=25a9wodafd4zh8w0lzpklf8lnc7mxwbm; expires=Sat, 07-May-2016 22:33:44 GMT; Max-Age=1209600; Path=/
Vary:Cookie, Accept-Encoding
X-Frame-Options:DENY
X-Handled-By:127.0.0.1:8000
Here is the response I'm getting in Android through our Cordova app:
Response Headers
Connection:keep-alive
Content-Encoding:gzip
Content-Length:654
Content-Type:application/json; charset=utf-8
Date:Sat, 23 Apr 2016 22:52:23 GMT
ETag:"11186a50be09093d01d4e82ff4d9d3e5;gzip"
Server:nginx/1.8.1
Vary:Cookie, Accept-Encoding
X-Frame-Options:DENY
X-Handled-By:127.0.0.1:8000
The request succeeds and the user somehow has a session and can make purchases. They can background the app and bring it up and their session is still there, but if they kill the app and bring it back up, they lose their session.
When I connect the Safari web debugger to our iOS Cordova app, the login response looks good. The sessionid cookie appears in the response header and everything works.
I'm hoping that there's something obvious about this whole process that I'm missing.

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

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>