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-boun...@lists.webkit.org [mailto:webkit-gtk-boun...@lists.webkit.org] On Behalf Of Carlos Garcia Campos Sent: 19 July 2013 15:49 To: webkit-gtk@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.h...@samsung.com<mailto:brian.h...@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 _______________________________________________ webkit-gtk mailing list webkit-gtk@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-gtk
