[Webkit-unassigned] [Bug 99352] [GTK] [WebKit2] Add an 'authenticate' signal to WebKitWebView

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=99352





--- Comment #27 from Carlos Garcia Campos <cgarcia at igalia.com>  2013-07-24 08:57:28 PST ---
(In reply to comment #26)
> (In reply to comment #22)
> > (In reply to comment #21)
> > > (In reply to comment #17)
> > > > Thanks for working on this! As an uzbl developer, is see a few things missing. It would be nice to have the "realm" if possible for the request; the host and/or URI might not be unique enough. 
> > > 
> > > I'm not quite sure what you mean by "realm", could you expand a bit on how you would like to see this implemented? 
> > 
> > The realm is available in the WebCore::AuthenticationChallenge. note that the user should be able to build the exact same auth dialog that wk uses by default with the public API.
> 
> I agree completely but I've been wondering how far to take this.  The WebKitAuthenticationDialog and WebKitAuthenticationWidget currently use the AuthenticationChallengeProxy directly, should it be refactored to use the public API of WebKitAuthenticationRequest? Perhaps then I could remove the private function webkitAuthenticationRequestGetAuthenticationChallenge() which would be substituted by _get_realm(), _get_host(), _get_port()?

WebKitAuthWidget is in WebCore so it can't use the public API. And the AuthDialog doesn't use the auth challenge except to create the WebKitAuthWidget, no? I think we can just add methods to get host, port, realm, etc. caching the required string on demand, so that when the default dialog is used we are not duplicating any string.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.