[webkit-gtk] Authentication dialog API

[Brian Holt]

Hi Carlos, 

Thanks for your comments and suggestions.  I've just uploaded a second patch, renaming the signal to "authenticate" and the request class  WebKitWebViewAuthenticationRequest now has the API you suggested.

Any other feedback and comments welcome.

Regards
Brian

-----Original Message-----
From: webkit-gtk-bounces at lists.webkit.org [mailto:webkit-gtk-bounces at lists.webkit.org] On Behalf Of Carlos Garcia Campos
Sent: 19 July 2013 15:49
To: webkit-gtk at lists.webkit.org
Subject: Re: [webkit-gtk] Authentication dialog API

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