https://issues.apache.org/jira/browse/CB-4093
On Mon, Jul 8, 2013 at 3:01 PM, Shazron <[email protected]> wrote: > +! > > > On Mon, Jul 8, 2013 at 5:41 AM, Andrew Grieve <[email protected]>wrote: > >> I meant it wouldn't be possible to route the callback to JS. >> >> With UriResolver.java, Android plugins could actually implement their own >> whitelist now. For iOS, NSURLProtocol would let you do this as well. So, >> we >> could move the whitelist to be a plugin at least on iOS & Android. Let's >> unify first though. >> >> >> On Sat, Jul 6, 2013 at 7:18 PM, Andrew Lunny <[email protected]> wrote: >> >> > Knowing the type of request is the tricky bit. >> > >> > I haven't looked at the relevant code in a long time, but your approach >> > sounds sound; it's similar to the chrome webRequest module: >> > http://developer.chrome.com/extensions/webRequest.html >> > >> > >> > On 6 July 2013 15:34, Michal Mocny <[email protected]> wrote: >> > >> >> Not sure I understand how it is that this cannot be supported.. >> >> >> >> Couldn't we allow native plugins to register synchronous "observers" >> for >> >> the CDVWhitelist URLIsAllowed method, and move the current >> implementation >> >> out to a core plugin? Then if your app wants something more >> complicated, >> >> you can just write a plugin for it. >> >> >> >> Looking again at your email, perhaps you mean just that its not >> possible >> >> to know the type of request? >> >> >> >> -Michal >> >> >> >> >> >> On Sat, Jul 6, 2013 at 3:47 PM, Andrew Lunny <[email protected]> wrote: >> >> >> >>> Yeah it's probably not practical right now. Roll on the >> >>> NavigationController :) >> >>> >> >>> Unifying the declarative whitelist is definitely worthwhile. >> >>> >> >>> >> >>> On 5 July 2013 16:03, Andrew Grieve <[email protected]> wrote: >> >>> >> >>> > Love that idea Andrew, but not sure it's doable on iOS. There's no >> >>> native >> >>> > callback that would tell us the type of request. We could try and >> pipe >> >>> > through the request URLs to JS, but since our network interception >> >>> happens >> >>> > on a non-UI thread, that would require proxying all requests, which >> is >> >>> > tough to get right. On Android, the situation is actually the same! >> >>> (ugh). >> >>> > >> >>> > I'm hoping that at least unifying our declarative whitelist should >> be a >> >>> > small amount of work. I know at least for Android and iOS it will >> >>> require >> >>> > only small tweaks. >> >>> > >> >>> > >> >>> > On Fri, Jul 5, 2013 at 4:07 PM, Andrew Lunny <[email protected]> >> wrote: >> >>> > >> >>> >> We ran into a lot of issues with this at PhoneGap Build, when I was >> >>> >> there. It's very difficult to anticipate all of the use cases that >> app >> >>> >> developers will have (what kind of resources should be allowed from >> >>> which >> >>> >> domains, where links should open, if links should be followed, etc >> >>> etc). >> >>> >> >> >>> >> One lower-level option would be to expose a function like iOS's >> >>> >> shouldStartLoadWithRequest[1], which gets passed the URL and the >> type >> >>> of >> >>> >> request (script, image, xhr, etc) and returns true/false as to >> >>> whether the >> >>> >> request should be allowed. This would allow for access policies >> that >> >>> are >> >>> >> unwieldy or impossible to express declaratively, and as >> fine-grained >> >>> as any >> >>> >> developer could want. Not sure where that would live in a Cordova >> 3.0 >> >>> >> universe though. >> >>> >> >> >>> >> [1]: >> >>> >> >> >>> >> http://developer.apple.com/library/ios/#documentation/uikit/reference/UIWebViewDelegate_Protocol/Reference/Reference.html#//apple_ref/occ/intf/UIWebViewDelegate >> >>> >> >> >>> >> >> >>> >> On 5 July 2013 12:21, Brian LeRoux <[email protected]> wrote: >> >>> >> >> >>> >>> TBH I'm still unsure of the entire whitelist thing. It feels like >> >>> >>> we've spent a great deal of time on a feature that is essentially >> >>> just >> >>> >>> a talking point for security checklists. Our community is >> otherwise >> >>> >>> uninterested if not outright frustrated by it! >> >>> >>> >> >>> >>> I know the whitelist is pretty tied up to our internals so making >> it >> >>> a >> >>> >>> plugin is probably not realistic. Regardless the behavior should >> be >> >>> >>> normalized across the platforms. I like the Chrome spec. >> >>> >>> >> >>> >>> We should contrast this with the WebAPI [1] stuff Moz is doing and >> >>> the >> >>> >>> restricted by default Sys Apps thinking [2]. >> >>> >>> >> >>> >>> [1] >> >>> >>> >> >>> >> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Security_model >> >>> >>> [2] http://runtime.sysapps.org/#csp-policy >> >>> >>> >> >>> >>> >> >>> >>> On Fri, Jul 5, 2013 at 12:00 PM, Andrew Grieve < >> [email protected] >> >>> > >> >>> >>> wrote: >> >>> >>> > As another point of reference, here's the white-listing scheme >> that >> >>> >>> Chrome >> >>> >>> > extensions use: >> >>> >>> > >> >>> >>> > http://developer.chrome.com/extensions/match_patterns.html >> >>> >>> > >> >>> >>> > It uses * for wildcards, but adds some restrictions as to where >> >>> the * >> >>> >>> may >> >>> >>> > appear and what schemes are valid. >> >>> >>> > >> >>> >>> > It's not a goal for Cordova to be runnable within Widget >> >>> containers, >> >>> >>> so I >> >>> >>> > don't think conforming to the widget spec is meaningful, except >> >>> that it >> >>> >>> > saves us from writing our own spec. I think the white-list >> patterns >> >>> >>> from >> >>> >>> > Chrome Extensions make sense (aside from specifying >> >>> "chrome-extension" >> >>> >>> as a >> >>> >>> > valid scheme). >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > On Fri, Jul 5, 2013 at 2:27 PM, Andrew Grieve < >> >>> [email protected]> >> >>> >>> wrote: >> >>> >>> > >> >>> >>> >> We've had several requests for finer-grain whitelist. The main >> >>> ask is >> >>> >>> a >> >>> >>> >> way to allow images. >> >>> >>> >> >> >>> >>> >> I think a simple step towards this would be to allow the >> >>> whitelist to >> >>> >>> >> specify patterns that match against the full URL, and not just >> the >> >>> >>> domain. >> >>> >>> >> >> >>> >>> >> e.g. <access origin="*.google.com/images/*" /> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> On Fri, Jul 5, 2013 at 2:05 PM, Ian Clelland < >> >>> [email protected] >> >>> >>> >wrote: >> >>> >>> >> >> >>> >>> >>> There seem to be two competing methods for whitelisting >> domains >> >>> with >> >>> >>> >>> subdomains, and support for each varies by platform. >> >>> >>> >>> >> >>> >>> >>> <access origin="*.example.com" /> >> >>> >>> >>> >> >>> >>> >>> - is supported on ios >> >>> >>> >>> - is supported on android as of CB-3854 >> >>> >>> >>> - is backwards-compatible with previous versions of cordova >> >>> >>> >>> - is supported by cordova-cli >> >>> >>> >>> >> >>> >>> >>> <access origin="example.com" subdomains="true" /> >> >>> >>> >>> >> >>> >>> >>> - is supported on android >> >>> >>> >>> - is supported on BB10 >> >>> >>> >>> - may not be backwards-compatible >> >>> >>> >>> - is the only method defined in the W3 widgets-access spec >> >>> >>> >>> - is not supported by cordova-cli* >> >>> >>> >>> >> >>> >>> >>> This situation makes it difficult to create a config.xml for a >> >>> >>> project >> >>> >>> >>> which will successfully work on all platforms. >> >>> >>> >>> >> >>> >>> >>> *(cordova-mobile-spec, for instance, contains <access origin=" >> >>> >>> apache.org" >> >>> >>> >>> subdomains="true" /> in its config.xml, which gets translated >> as >> >>> >>> <access >> >>> >>> >>> origin="apache.org" /> in the platform config files, and >> >>> >>> subsequently >> >>> >>> >>> fails >> >>> >>> >>> everywhere.) >> >>> >>> >>> >> >>> >>> >>> I think that the subdomains attribute is the right way >> forward, >> >>> as >> >>> >>> it is >> >>> >>> >>> endorsed by the W3C, and I believe that we are ostensibly >> trying >> >>> to >> >>> >>> >>> conform >> >>> >>> >>> to the widgets spec for our config.xml files. >> >>> >>> >>> >> >>> >>> >>> To that end, I'd like to make the subdomains attribute work on >> >>> all >> >>> >>> >>> platforms (I'll take care of iOS; I don't know if any others >> need >> >>> >>> fixing) >> >>> >>> >>> and also make it work in CLI. I don't think we should remove >> >>> support >> >>> >>> for >> >>> >>> >>> the wildcard domains, for backwards compatibility, but then >> >>> again, >> >>> >>> maybe >> >>> >>> >>> 3.0 is the right time and place for that. >> >>> >>> >>> >> >>> >>> >>> If there are no objections, I'll create the issues and start >> >>> >>> implementing >> >>> >>> >>> this (with as much backwards compatibility as I can manage) >> >>> >>> >>> >> >>> >>> >>> Ian >> >>> >>> >>> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >>> >> >> >>> >> >> >>> > >> >>> >> >> >> >> >> > >> > >
