[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