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