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