[Webkit-unassigned] [Bug 210298] [ITP] Cross Domain SSO cookies not sent in Safari 13.1/STP 104

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Apr 9 13:26:47 PDT 2020


https://bugs.webkit.org/show_bug.cgi?id=210298

--- Comment #3 from John Wilander <wilander at apple.com> ---
(In reply to John Wilander from comment #2)
> Hi!
> 
> Thank you for filing!
> 
> *.example.com having its cookie access blocked when third-party under
> *.example.ca is intentional which you probably know from reading the latest
> ITP blog post.
> 
> Here's what you can do if you want to make use of the Storage Access API:
> 
> 1. When you navigate the top frame to *.example.com and set its
> authentication cookie, don't just redirect back to *.example.ca because
> doing so means *.example.com is behaving like a bounce tracker. Instead stop
> at *.example.com and have the user interact with the *.example.com website.
> This could be a confirm button or such, and gives the user a chance to see
> the *.example.com and understand that it is involved in the *.example.ca
> functionality. Make sure to set the authentication cookie while on
> *.example.com as first-party website since third-parties without
> pre-existing cookies cannot set cookies in Safari.
> 
> 2. Take the user back to *.example.ca and serve a third-party iframe from
> *.example.com on that page.
> 
> 3. Have the user interact with the third-party iframe from *.example.com
> under *.example.ca. This could be tapping/clicking on a button in the iframe.
> 
> 4. On the event handler of that tap/click in the third-party iframe from
> *.example.com, you should see Safari prompt the user and ask if they are
> willing to allow storage access to *.example.com under *.example.ca.

Sorry, I meant to say you call document.requestStorageAccess() on that event handler and then should expect to see the prompt.

> 5. If the user opts in, the iframe from *.example.com now should have cookie
> access. It can navigate same-site and still maintain cookie access. However,
> when the iframe goes away, so does its storage access.
> 
> 6. Subsequent taps/clicks on third-party iframes from *.example.com under.
> *.example.ca which call the Storage Access API on the event handler will not
> prompt the user since the user has already opted in. Instead, storage access
> will be granted immediately.
> 
> Let me know if the above works for you. Thanks!

-- 
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/20200409/4d69f2c2/attachment.htm>


More information about the webkit-unassigned mailing list