Bug 188783

Summary:

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

Product:

WebKit

Reporter:

Ulf Liedberg <ulf>

Component:

New Bugs

Assignee:

John Wilander <wilander>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

achristensen, commit-queue, webkit-bug-importer, wilander

Priority:

Keywords:

InRadar

Version:

Safari Technology Preview

Hardware:

Mac

OS:

macOS 10.13

See Also:

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

Attachments:

Description	Flags
Patch	none

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

<rdar://problem/43559215>

Comment 3 John Wilander 2018-08-21 14:56:48 PDT

Created attachment 347705 [details]
Patch

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]
Patch

Thanks, Alex!

Comment 6 WebKit Commit Bot 2018-08-21 16:32:39 PDT

Comment on attachment 347705 [details]
Patch

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!