[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_API void
> webkit_authentication_dialog_request_set_username (WebKitAuthenticationDialogRequest *request,
> const gchar *username);
>
> WEBKIT_API const gchar *
> webkit_authentication_dialog_request_get_username (WebKitAuthenticationDialogRequest *request);
>
> WEBKIT_API void
> 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_API void
> 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_API void
> 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_API void
> webkit_authentication_dialog_request_authenticate (WebKitAuthenticationDialogRequest *request);
>
> WEBKIT_API void
> 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
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- 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