| Subject: | New default SameSite=Lax setting causes breakage for us |
We recently upgraded some systems, and this took us from Catalyst::Plugin::Session::State::Cookie 0.17 to 0.18, resulting in a new SameSite=Lax cookie attribute being sent.
Unfortunately, this caused breakage to an Android app which talks to our Catalyst-powered API - after a fair bit of head-scratching and puzzlement, I found a warning in Chrome's dev tools while inspecting the WebView component in the app, that:
This Set-Cookie was blocked because it has the "SameSite=Lax" attribute but came
from a cross-site response which was not the response to a top-level navigation
This puzzles me a little as "Lax" is supposed to be modern browsers default behaviour if you hadn't set the SameSite attribute at all, so setting it to that *shouldn't* have changed anything, to my understanding.
It's possible that the problem wouldn't have occurred if the cookie had the Secure attribute set - but ours don't, for now at least, as there are some legacy apps out there still which have problems with SSL.
Once we can enable the `Secure` attribute then we can specifically configure for `SameSite=None` and things should be fine, but in the meantime, the default addition of the header breaks things for us and we have to pin to 0.17 to avoid it - so figured I'd report it here for anyone else's reference. Maybe there could be some clarification in the docs?
Or maybe it should be possible to set the `cookie_samesite` config option to `omit` or something similar, to say "no, don't add the SameSite attribute for me at all"? That would have allowed us to work round this easily for now.
As an aside: I think the WebView component in the app sees it as a cross-site response because it sees the app's HTML&JS content as coming from a file:/// URL on the device.