cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Whitelist: *.doman vs subdomain attribute
Date Fri, 05 Jul 2013 18:27:33 GMT
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 <iclelland@chromium.org> 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
>

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