Bug 188783 – Cookies not available when requestStorageAccess successfully resolves after "allow" in ITP prompt

• Component: New Bugs
• Status: RESOLVED FIXED

[Ulf Liedberg]

John Wilander asked me to file a bug here after a bit of discussion on twitter. Not sure if I'm misunderstanding/misusing the Storage Access API but here's my case. 

When the user answers "allow" on the ITP prompt the cookies are not available in the 3rd party context directly. Not in the requestStorageAccess success callback and not afterwards. If the iframe is __reloaded__ and requestStorageAccess called it's, as expected, automatically successfully resolved and I have access to cookies.

Reproduction repo: https://github.com/uliedberg/itp2-test/tree/master/basic-basic-browser-set-cookies-only . I've also put up the main & third party parts on different domains for easier reproduction.

The third party iframe page will call hasStorageAccess() on load.

* > defaults write com.apple.SafariTechnologyPreview ResourceLoadStatisticsManualPrevalentResource liedberg.org
* in Safari Technology Preview 63, clear history and then open: 
	- https://www.alfhild.io/itp2/main/?thirdparty-url=https%3A%2F%2Fwww.liedberg.org%2Fitp2%2Fthirdparty%2F
1. Click "open popup" link (third party in main page)
2. Click "write cookie" link (popup page)
3. Click "close" link (popup page)
4. Click "request access" link (third party in main page)
5. Select "allow" in ITP prompt (main page)
	- at this point the third party iframe tries to read the cookie but no value
6. Click "read cookie" link (third party in main page)
	- no value still
7. Click "reload iframe" link (third party in main page)
8. Click "request access" link (third party in main page)
	- __now__ the cookies are available

[John Wilander]

Thanks, Ulf!

[Radar WebKit Bug Importer]

<rdar://problem/43559215>

[John Wilander]

Created attachment 347705 [details]
Patch

[John Wilander]

I found the bug, and it's related to the other bug you reported about the prompt showing the full host names instead of eTLD+1s.

The specific code path for the prompt sends the host names instead of the eTLD+1s which means storage access is granted for the host and not the eTLD+1. Then, when cookie resolution happens, there is no storage access entry for the eTLD+1 and thus no cookies.

The second code path, i.e. without a prompt, correctly stores and entry for the eTLD+1 and resolution works.

Again, thanks for the bug report, Ulf!

[John Wilander]

Comment on attachment 347705 [details]
Patch

Thanks, Alex!

[WebKit Commit Bot]

Comment on attachment 347705 [details]
Patch

Clearing flags on attachment: 347705

Committed r235145: <https://trac.webkit.org/changeset/235145>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Ulf Liedberg]

Happy to help!