You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following a conversation the other day, I think we need to clarify what the "site for cookies" is in the case of redirects.
The relevant section of the specification reads:
If "request"'s client is "null", return "same-site".
Note that this is the case for navigation triggered by the user
directly (e.g. by typing directly into a user agent's address
bar).
I take this to mean that for the first request (the request that the user initiated) the client is null and, therefore, same-site - but for subsequent requests, since they're initiated by the redirect, they may be treated as cross-site requests (if 'target' differs from 'site').
This differs from the Chrome implementation's current behavior. I think, for strict same site cookies at least, this perhaps needs tightening up.
Thoughts?
The text was updated successfully, but these errors were encountered:
mnot
changed the title
rfc6265bis - Same-Site cookies - clarify "site for cookies" in the case of redirects
Same-Site cookies - clarify "site for cookies" in the case of redirects
Apr 30, 2018
Could you provide the examples you're thinking of for request chains starting out non-null and becoming null, please? Is iframe sandboxing at play here? Or are we talking about redirects to schemes such as about:, javascript: etc? Are there cases outside web browsing contexts?
A request's client does not change during redirects. It's generally null during navigation from the address bar, and remains null through the redirect chain (e.g. navigating to http://bit.ly/31ZtzXa is considered strictly same-site to https://github.com/w3c/webappsec/blob/master/meetings/2019/2019-09-TPAC-minutes.md upon which it lands). That behavior seems reasonable to me, if only because of the variety of places I've worked that have internal redirect servers that allow you to type something exciting like go/somewhere-useful to go somewhere useful. It would be unfortunate, I think, if users weren't signed in after using such a service.
It looks like there's disagreement between Firefox and Chrome here (Chrome sends SameSite=Strict cookies, Firefox only sends SameSite=Lax). I don't have Safari in front of me to test, but I can probably check it tonight.
Following a conversation the other day, I think we need to clarify what the "site for cookies" is in the case of redirects.
The relevant section of the specification reads:
I take this to mean that for the first request (the request that the user initiated) the client is null and, therefore, same-site - but for subsequent requests, since they're initiated by the redirect, they may be treated as cross-site requests (if 'target' differs from 'site').
This differs from the Chrome implementation's current behavior. I think, for strict same site cookies at least, this perhaps needs tightening up.
Thoughts?
The text was updated successfully, but these errors were encountered: