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