For Android, I see what you are saying. At best it’s a slightly better situation than the plugin I initially mentioned. You could check the cert in the shouldInterceptRequest and return null if it was OK, or something else if it was not (like the current whitelist checks), but the *actual request* would still be separate from the one that was actually tested.
Just to further cloud the waters… if we *did* implement it this way, it would double the latency on every request to a pinned host. :( Hrm… I might have to solve this outside of core unless we can come up with an idea how to do it. /me feels a plugin that polyfills xhr coming… ugh... On 14 Jan 2014, at 1:28 pm, Andrew Grieve <agri...@chromium.org> wrote: > Implementation notes that come to mind: > > Android: > I think this will actually be impossible to do on Android :(. > shouldInterceptRequest is the closest thing you'd need, as it's your > hook for overriding network requests. However, it exposes only the URL > that is being requests. Not the HTTP method, not any request headers, > not the request payload. :(. You could add it in for FileTransfer > though. You could also add it in using a strange different API (e.g. > set headers, method, payload using exec(), then use an XHR to fire the > request). For GET requests, it matters less since you can get the > Cookies for it, but still are lacking custom headers. > > iOS: > URLProtocol is the way to go. As long as the URL is whitelisted, > Cordova's won't touch it and your registered protocol will pick it up. > CDVProtocol should at least provide a helper method for mapping a > request to a UIWebView though. But I do think multiple URLProtocol > handlers will work fine. > From past experience, if you use NSURLConnection to implement all > UIWebView requests, then it will work just fine... except for hanging > gets. NSURLConnection buffers responses and so won't trickle data down > to you as it comes, which hanging gets require. Not a big deal... > unless you want to use a hanging get. > > > > > > > > On Mon, Jan 13, 2014 at 5:13 PM, Joe Bowser <bows...@gmail.com> wrote: >> On Mon, Jan 13, 2014 at 2:00 PM, Tommy-Carlos Williams >> <to...@devgeeks.org> wrote: >>> Marcel, >>> >>> Well, I was hoping it would not come down to custom TrustManagers. I was >>> hoping to hook into the CordovaWebViewClient’s shouldInterceptRequest(). >>> >>> I realise this is in API 11+, but don’t know of another way off the top of >>> my head (was hoping this thread could help, yay). >>> >>> Is the issue related to that “security hole” thread where the whitelist >>> isn’t checked with ajax/xhr on API < 11 ? >>> >> >> Yup. There's no such thing as shouldInterceptRequest() in >> Gingerbread. I think we should just assume that anyone who owns a >> Gingerbread phone is already owned based on the tons of other known >> security flaws on that device and just move on. >> >>> >>> >>> >>> On 14 Jan 2014, at 8:53 am, Marcel Kinard <cmarc...@gmail.com> wrote: >>> >>>> I am curious how this would be implemented on Android. If you construct an >>>> SSLSocketFactory with your private TrustManager that contains the pinned >>>> cert, how do you get the Android webview to use that SSLSocketFactory? >>>> >>>
