No way to handle HTTP Authentication with WKWebView
Created attachment 233368 [details] Patch
Created attachment 233371 [details] Patch
Comment on attachment 233371 [details] Patch Nice writeup
<rdar://problem/17317874>
Committed r170157: <http://trac.webkit.org/changeset/170157>
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.
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.
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.