Bug 134067 – No way to handle HTTP Authentication with WKWebView

• Component: New Bugs
• Status: RESOLVED FIXED

[Anders Carlsson]

No way to handle HTTP Authentication with WKWebView

[Anders Carlsson]

Created attachment 233368 [details]
Patch

[Anders Carlsson]

Created attachment 233371 [details]
Patch

Comment on attachment 233371 [details]
Patch

Nice writeup

<rdar://problem/17317874>

[Anders Carlsson]

Committed r170157: <http://trac.webkit.org/changeset/170157>

[Ryosuke Niwa]

Looks like this patch caused a build failure on commit queue. I've posted a patch on https://bugs.webkit.org/show_bug.cgi?id=134152.

[Alexey Proskuryakov]

Does this support all kinds of challenges, or only username/password?

I'm thinking of finally reenabling HTTPS regression tests in WKTR - to do this, we need to handle server trust auth.

(In reply to comment #7)
> Does this support all kinds of challenges, or only username/password?

It supports username/password and client certificate authentication, but not server trust, which is why the “can authenticate” client function returns false for server trust.

> I'm thinking of finally reenabling HTTPS regression tests in WKTR - to do this, we need to handle server trust auth.

I looked into enabling server trust authentication a couple of times, and each time my conclusion was that Security and CFNetwork are missing the API needed for that.

[Alexey Proskuryakov]

Is there a bug tracking the missing API?

From looking at <https://developer.apple.com/library/Mac/documentation/Cocoa/Conceptual/URLLoadingSystem/Articles/AuthenticationChallenges.html>, it appears that we should simply return YES from canAuthenticate..., and then pass [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] to useCredential. It seemed to me that we lose the ability to do so at WebKit2 layer.

(In reply to comment #9)
> Is there a bug tracking the missing API?
> 
> From looking at <https://developer.apple.com/library/Mac/documentation/Cocoa/Conceptual/URLLoadingSystem/Articles/AuthenticationChallenges.html>, it appears that we should simply return YES from canAuthenticate..., and then pass [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] to useCredential. It seemed to me that we lose the ability to do so at WebKit2 layer.

It’s been a few days since I last looked at it, so I am not sure I remember correctly, but I seem to remember that the issues were: server trust is a write-only property of a NSURLCredential and a read-only property of a NSURLProtectionSpace.

(In reply to comment #10)
> (In reply to comment #9)
> > Is there a bug tracking the missing API?
> > 
> > From looking at <https://developer.apple.com/library/Mac/documentation/Cocoa/Conceptual/URLLoadingSystem/Articles/AuthenticationChallenges.html>, it appears that we should simply return YES from canAuthenticate..., and then pass [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] to useCredential. It seemed to me that we lose the ability to do so at WebKit2 layer.
> 
> It’s been a few days since I last looked at it, so I am not sure I remember correctly, but I seem to remember that the issues were: server trust is a write-only property of a NSURLCredential and a read-only property of a NSURLProtectionSpace.

We now use the platform encoding of NSURLProtectionSpace, and we’ll be able to support server trust authentication if we do the same for NSURLCredential. I filed bug 135327.