Bug 188783 - Cookies not available when requestStorageAccess successfully resolves after "allow" in ITP prompt
Summary: Cookies not available when requestStorageAccess successfully resolves after "...
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: Safari Technology Preview
Hardware: Mac macOS 10.13
: P2 Normal
Assignee: John Wilander
Keywords: InRadar
Depends on:
Reported: 2018-08-21 04:36 PDT by Ulf Liedberg
Modified: 2018-08-21 23:45 PDT (History)
4 users (show)

See Also:

Patch (2.07 KB, patch)
2018-08-21 14:56 PDT, John Wilander
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ulf Liedberg 2018-08-21 04:36:25 PDT
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
Comment 1 John Wilander 2018-08-21 06:36:44 PDT
Thanks, Ulf!
Comment 2 Radar WebKit Bug Importer 2018-08-21 06:37:22 PDT
Comment 3 John Wilander 2018-08-21 14:56:48 PDT
Created attachment 347705 [details]
Comment 4 John Wilander 2018-08-21 15:01:33 PDT
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!
Comment 5 John Wilander 2018-08-21 15:25:45 PDT
Comment on attachment 347705 [details]

Thanks, Alex!
Comment 6 WebKit Commit Bot 2018-08-21 16:32:39 PDT
Comment on attachment 347705 [details]

Clearing flags on attachment: 347705

Committed r235145: <https://trac.webkit.org/changeset/235145>
Comment 7 WebKit Commit Bot 2018-08-21 16:32:41 PDT
All reviewed patches have been landed.  Closing bug.
Comment 8 Ulf Liedberg 2018-08-21 23:45:51 PDT
Happy to help!