[webkit-gtk] Authentication dialog API

Carlos Garcia Campos cgarcia at igalia.com
Fri Jul 19 07:48:58 PDT 2013

El vie, 19-07-2013 a las 14:21 +0000, Brian Holt escribió:
> Hi WebKitGtk+,
> I'm creating the API for the Authentication Dialog (see
> https://trac.webkit.org/wiki/WebKitGTK/WebKit2Roadmap) tracked under
> https://bugs.webkit.org/show_bug.cgi?id=99352.  The basic idea is that
> some application authors might want to bring up their own
> authentication dialog for http authentication, and so this work is to
> enable them to do so by connecting to a new signal and interacting
> with a new API.

Not necessarily a dialog, API users could use any auth mechanism, as
long as they provide a user/pass. So I would avoid the word dialog,
WebKitWebView::authenticate and WebKitWebViewAuthenticationRequest sound
good to me.

> A prototype is working, now I just need to check that I've got the
> names and architecture right.
> When  WebLoaderClient::didReceiveAuthenticationChallengeInFrame() is
> called I propose to create a new WebkitAuthenticationDialogRequest
> object. This class will be the public interface for the authentication
> request and I propose that it have the following public API:
> webkit_authentication_dialog_request_set_username                        (WebKitAuthenticationDialogRequest *request,
>                                                                                                                                          const gchar *username);
> WEBKIT_API const gchar *
> webkit_authentication_dialog_request_get_username                        (WebKitAuthenticationDialogRequest *request);
> webkit_authentication_dialog_request_set_password                        (WebKitAuthenticationDialogRequest *request,
>                                                                                                                                         const gchar* password);
> WEBKIT_API const gchar *
> webkit_authentication_dialog_request_get_password                        (WebKitAuthenticationDialogRequest *request);

Instead of having get and set for the user/pass I think the request
should be created with the user/pass of the challenge in case it was
stored in the keyring, and new user/pass should be passed in the
authenticate method, together with the storage option.

> webkit_authentication_dialog_request_set_remember_password               (WebKitAuthenticationDialogRequest *request,
>                                                                                                                                                        gboolean remember);
> WEBKIT_API gboolean
> webkit_authentication_dialog_request_get_remember_password               (WebKitAuthenticationDialogRequest *request);

Instead of a boolean this should probably be an enum that would allow us
to extend it in the future to support other persistence modes like
permanent, session and none, for example.

> webkit_authentication_dialog_request_set_private_browsing                (WebKitAuthenticationDialogRequest *request,
>                                                                                                                                                 gboolean privateBrowsingEnabled);
> WEBKIT_API gboolean
> webkit_authentication_dialog_request_get_private_browsing                (WebKitAuthenticationDialogRequest *request);

We have a setting for this, so I think it should be handled internally,
probably ignoring the saving mode when private browsing is enabled.

> webkit_authentication_dialog_request_authenticate                        (WebKitAuthenticationDialogRequest *request);
> webkit_authentication_dialog_request_cancel                              (WebKitAuthenticationDialogRequest *request);
> To support the existing webkitAuthenticationDialog  custom widget
> without much change I propose to also support a private pair of
> functions to access the AuthenticationChallengeProxy*
> void
> webkit_authentication_dialog_request_set_authentication_challenge  (WebKitAuthenticationDialogRequest *request,
>                                                                                                                                                    WebKit::AuthenticationChallengeProxy * authenticationChallenge);
> WebKit::AuthenticationChallengeProxy*
> webkit_authentication_dialog_request_get_authentication_challenge  (WebKitAuthenticationDialogRequest *request);

Remember private functions should use the WebKit coding style.

> From WebLoaderClient::didReceiveAuthenticationChallengeInFrame(), the
> WebkitAuthenticationDialogRequest* is passed into the existing
> webkitWebViewHandleAuthenticationChallenge(...) (parameters now
> changed) which emits a new signal.
> I propose the signal name be "run-authentication-dialog", since in
> principle it is quite similar to "run-file-chooser" in that it brings
> up a dialog for the user to interact with.
> The default handler for the signal does what was previously done, i.e.
> call webkitWebViewRunAuthenticationDialog() which creates the custom
> webkitAuthenticationDialog.
> A WIP patch has been uploaded to
> https://bugs.webkit.org/show_bug.cgi?id=99352 if you want more detail.

Thanks, I'll review it.

> What do you think?
> Regards
> Brian
> Brian Holt
> Senior Software Engineer
> Samsung Electronics (UK) Limited
> Registered number:  03086621
> Registered address: Samsung House, 1000 Hillswood Drive, Chertsey,
>                     Surrey KT16 0PS, England
> South Street        Email:  brian.holt at samsung.com<mailto:brian.holt at samsung.com>
> Staines             Fax:    +44 (0)1784 428620
> MIDDLESEX           Office: +44 (0)1784 428600 (ext 380)
> TW18 4QE
> England

Carlos Garcia Campos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20130719/2f55e3e7/attachment-0001.sig>

More information about the webkit-gtk mailing list