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