cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: Whitelist: *.doman vs subdomain attribute
Date Fri, 05 Jul 2013 19:00:37 GMT
As another point of reference, here's the white-listing scheme that Chrome
extensions use:

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 <> 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="**" />
> On Fri, Jul 5, 2013 at 2:05 PM, Ian Clelland <>wrote:
>> There seem to be two competing methods for whitelisting domains with
>> subdomains, and support for each varies by platform.
>> <access origin="*" />
>>    - 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="" 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=""
>> subdomains="true" /> in its config.xml, which gets translated as <access
>> origin="" /> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message