[Webkit-unassigned] [Bug 210422] [GTK][WPE] Add API to expose UIClient::requestStorageAccessConfirm

[bugzilla-daemon at webkit.org]

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

--- Comment #9 from Michael Catanzaro <mcatanzaro at gnome.org> ---
Comment on attachment 401725
  --> https://bugs.webkit.org/attachment.cgi?id=401725
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=401725&action=review

>>> Source/WebKit/UIProcess/API/glib/WebKitWebsiteDataAccessPermissionRequest.cpp:34
>>> + * permission to allow a third-party domain access cookies and website data.
>> 
>> access to cookies and website data
>> 
>> Although, I'm not actually certain it *does* allow a third-party domain to access website data other than cookies. Are you sure about this? Firefox allows this according to https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API, but its documentation implies that WebKit does not. John would know exactly how this works.
> 
> I used the safari dialog message as a reference, see https://webkit.org/wp-content/uploads/storage-access-prompt.png

OK.

>>> Source/WebKit/UIProcess/API/glib/WebKitWebsiteDataAccessPermissionRequest.cpp:81
>>> +    webkitWebsiteDataAccessPermissionRequestDeny(WEBKIT_PERMISSION_REQUEST(object));
>> 
>> So I see this is copied from our various other permission request classes, but all those classes have a bool madeDecision member variable to track whether a permission request has previously been completed or not and only call the CompletionHandler if so. You don't have that here, so it's going to call the CompletionHandler again unconditionally. If you try this patch in a debug build, I think it's going to assert, because CompletionHandler is designed to assert when called twice.
> 
> We don't need an extra variable for that in this case because completion handler is false once it has been called, and I'm checking it's true before calling it in both Allow and Deny.

OK.

>>> Source/WebKit/UIProcess/API/glib/WebKitWebsiteDataAccessPermissionRequest.cpp:125
>>> + * Since: 2.30
>> 
>> Hm, I assumed that the domain requesting storage access only gets access to its *own* cookies (and maybe also other website data), not access to the first-party domain's data. Does it really get access to the data of the first-party domain? John?
>> 
>> Please investigate before landing; we need to be sure about this before we land this API.
> 
> Again I used the safari dialog as reference.

In this case, I think you misread the Safari dialog (although I might be wrong). I think the third-party domain is requesting access to its own cookies and website data, not the first-party domain's cookies and website data.

-- 
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/20200614/fd128dfb/attachment.htm>