[Webkit-unassigned] [Bug 219150] Safari does not allow first-party JS cookie to be set after SSO flow
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Nov 20 00:36:22 PST 2020
https://bugs.webkit.org/show_bug.cgi?id=219150
--- Comment #5 from Lukas Röllin (Swisscom) <lukas.roellin at swisscom.com> ---
I have made another finding.
- It seems like SameSite=Lax instead of SameSite=Strict seems to alleviate the problem
As flags go, we're using Secure, and until now SameSite=Strict.
Side note: we do not rely on cookies being sent to any backend server (they are on a completely different, non-user facing domain anyway). We authenticate our requests to our backend by manually setting an Authorization header (put together by reading the value in the cookie (and in-memory from then on)). So we rely only on having those cookies available via first-party JS.
Would you have any idea why SameSite=Lax cookies are allowed to be stored, while SameSite=Strict cookies do not, after an SSO flow?
As a definition, "allowed to be stored" means that I can
1. Set the cookies via document.cookie = '...'
2. Read the cookie via document.cookie = '...'
So far, 'not stored' meant that the (1) completed (without any error message in any console), while (2) was empty
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201120/7830c1a1/attachment.htm>
More information about the webkit-unassigned
mailing list