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