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 >> >>> >>> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> > >> > >
