On Wed, Jul 8, 2015 at 4:47 AM, Shazron <[email protected]> wrote: > FYI, we get to revisit this whitelist stuff again for iOS 9 with it's > Application Transport Security (ATS): > > https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/index.html#//apple_ref/doc/uid/TP40016240 > > Should be relatively simple --> convert access tags to the appropriate > Info.plist tags and not filter the request in CDVURLProtocol (which doesn't > work for WKWebView anyway). >
Neat! > > On Wed, Jul 8, 2015 at 1:43 AM, Shazron <[email protected]> wrote: > > > Related: https://issues.apache.org/jira/browse/CB-9329 > > > > From the README: https://github.com/apache/cordova-plugin-whitelist > > > > The Android whitelist supports <allow-navigation>, <allow-intent> and > > <access>. > > The iOS whitelist supports <allow-navigation> only currently. > This is certainly the most important one. > > > > The docs mention <access> SHOULD be supported, but CSP is the way to go. > > > > Therefore <access> needs to be supported on iOS for native code requests > > (see failing FileTransfer tests CB-9329) since CSP is only in the context > > of the UIWebView. This is duplication of definitions unless we read the > > meta tag from native and dynamically create the allowRequests whitelist > > plugin. > I think it'd be fine to just say iOS doesn't support <access>, so use CSP (although sounds like there is a way to add it via .plist, might be pretty low priority) > > > > <allow-intent> I think is the domain of the InAppBrowser plugin only > > (window.open). > This one was meant to enable things like tel: URLs that result in other applications being opened, so more the domain of the main webview I think (although I'm less knowledgeable about why we even want this whitelist, so not sure how important it is to implement) > > > > Am I missing anything? > > > > > > >
