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?
CodePudding user response:
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.
- 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
- 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.
- This comment talks about setting the
- Change cookie domain handling for IP address host