[Webkit-unassigned] [Bug 213177] [GTK][WPE] Add API to allow applications to handle the HTTP authentication credential storage

[bugzilla-daemon at webkit.org]

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

--- Comment #5 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Carlos Garcia Campos from comment #4)
> (In reply to Michael Catanzaro from comment #3)
> > Both options seem almost equally good, but since we have to pick one, I
> > guess I would slightly favor WebKitWebContext.
> 
> I decided to do both in the end:
> 
>   - I added a "global" setting to disable persistent credential storage (but
> to website data manager instead of web context). This way apps can simply
> disable persistent credential storage even if they are not going to handle
> the credentials at all.
> 
>   - Added webkit_authentication_request_set_proposed_credential() that
> allows apps to set the proposed credential from their own storage.
> 
>   - Added WebKitAuthenticationRequest::authenticated signal. Emitted when
> the authentication success with the accepted credentials to allow
> applications to save them.

Also added webkit_authentication_request_set_can_save_credentials() so that the auth dialog shows the remember checkbox even when persistent storage is disabled in WebKit.

> I have found two problems when starting to use this API in epiphany:
> 
>   1- Already remembered password will be lost from the user point of view.
> I'm not sure it's possible to write a migrator that reads the webkit
> passwords and stores them in ephy.
> 
>   2- We need to get the stored credentials synchronously, since we need to
> decide whether to return TRUE (when we have credentials and authenticate
> without showing the dialog) or FALSE to show the dialog. I don't know how to
> do this.

I managed to make 2 work, by always assuming we have credentials saved and returning TRUE to not show the dialog. If we finally get the credentials we just authenticate, otherwise we force a retry and then we check it's a retry and return FALSE to show the dialog.

-- 
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/20200623/5d0d8f38/attachment-0001.htm>