[webkit-gtk] Authentication dialog API
Brian Holt
brian.holt at samsung.com
Thu Jul 25 08:17:10 PDT 2013
Hi,
There still remains an open question about the ownership of the WebKitCredential object that could do with some discussion, but before we consider the arguments, here is some pseudocode of how I would envisage the API being used for a custom dialog:
gboolean runAuthenticateCallback(WebKitWebView*, WebKitAuthenticationRequest* request, gpointer) <- the signal handler for authenticate
{
WebKitCredential* credential = webkit_authentication_request_get_credential(request);
// use the proposed credential to populate the dialog
}
void okButtonClicked(GtkWidget* widget, gpointer)
{
// perhaps check whether the credentials are the same as the proposed credentials
WebKitAuthenticationRequest* request = priv->request;
// if not the same as stored
WebKitCredential* credential = webkit_credential_new(button.username, button.password, persistence);
// do the authentication
webkit_authentication_request_authenticate(request, credential)
}
The question to discuss now is how to best design the API regarding the ownership of the WebKitCredential. I see 2 main options:
1) The WebKitAuthenticationRequest caches the WebKitCredential and returns a const* in webkit_authentication_request_get_credential() (transfer none). The credential parameter in webkit_authentication_request_authenticate() is (transfer full). Memory is freed in (a) the request's destructor, (b) in authenticate() if a previous credential is present and (c) in the caller *if* the caller creates a WebKitCredential but doesn't pass it to authenticate(). This case is easy from the point of view of the client, you can create the credential, use it to authenticate and forget about it.
2) Do not cache the WebKitCredential. The WebKitCredential is created and returned each time webkit_authentication_request_get_credential() (transfer full) is called and webkit_authentication_request_authenticate() (transfer none) does not free the memory. It remains the responsibility of the client to always free using webkit_credential_free().
What do you think?
Regards
Brian
-----Original Message-----
From: webkit-gtk-bounces at lists.webkit.org [mailto:webkit-gtk-bounces at lists.webkit.org] On Behalf Of Brian Holt
Sent: 22 July 2013 17:08
To: webkit-gtk at lists.webkit.org
Subject: Re: [webkit-gtk] Authentication dialog API
Hi all,
After some feedback and comments here is a new proposal for the API:
The request object that will be emitted along with the "authenticate" signal is a WebKitAuthenticationRequest with this public interface
WEBKIT_API GType
webkit_authentication_request_get_type (void);
WEBKIT_API gboolean
webkit_authentication_request_can_save_credential (WebKitAuthenticationRequest *request);
WEBKIT_API WebKitCredential*
webkit_authentication_request_get_credential (WebKitAuthenticationRequest *request);
WEBKIT_API void
webkit_authentication_request_authenticate (WebKitAuthenticationRequest *request,
WebKitCredential *credential);
WEBKIT_API void
webkit_authentication_request_cancel (WebKitAuthenticationRequest *request);
webkit_authentication_request_can_save_credential() will return FALSE if private browsing is enabled or if there is no libsecret support.
A new class WebKitCredential is provided to encapsulate the credential, which simplifies the API will also allow us to add support for client certificate authentication using the same API in the future. The user can pass back the existing credential or can create a new one prior to authentication. The public API for this object would look as follows:
WEBKIT_API GType
webkit_credential_get_type (void);
WEBKIT_API WebKitCredential *
webkit_credential_ref (WebKitCredential *credential);
WEBKIT_API void
webkit_credential_unref (WebKitCredential *credential);
WEBKIT_API WebKitCredential *
webkit_credential_new (const gchar *username, const gchar *password, WebKitCredentialPersistence persistence);
WEBKIT_API const gchar *
webkit_credential_get_username (WebKitCredential *credential);
WEBKIT_API const gchar *
webkit_credential_get_password (WebKitCredential *credential);
WEBKIT_API WebKitCredentialPersistence
webkit_credential_get_persistence (WebKitCredential *credential);
Does this seem like a reasonable approach?
Regards
Brian
-----Original Message-----
From: webkit-gtk-bounces at lists.webkit.org [mailto:webkit-gtk-bounces at lists.webkit.org] On Behalf Of Brian Holt
Sent: 19 July 2013 18:03
To: 'Carlos Garcia Campos'; webkit-gtk at lists.webkit.org
Subject: Re: [webkit-gtk] Authentication dialog API
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
_______________________________________________
webkit-gtk mailing list
webkit-gtk at lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk
_______________________________________________
webkit-gtk mailing list
webkit-gtk at lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk
More information about the webkit-gtk
mailing list