Summary: | No way to handle HTTP Authentication with WKWebView | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Anders Carlsson <andersca> | ||||||
Component: | New Bugs | Assignee: | Anders Carlsson <andersca> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | ap, mitz, rniwa | ||||||
Priority: | P2 | Keywords: | InRadar | ||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
Anders Carlsson
2014-06-19 11:12:16 PDT
Created attachment 233368 [details]
Patch
Created attachment 233371 [details]
Patch
Comment on attachment 233371 [details]
Patch
Nice writeup
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. |