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

[bugzilla-daemon at webkit.org]

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

--- Comment #2 from John Wilander <wilander at apple.com> ---
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.

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/b6e74b01/attachment-0001.htm>