cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: Whitelist: *.doman vs subdomain attribute
Date Fri, 05 Jul 2013 19:17:48 GMT
That spec does have offer couple of advantages over the widget spec:
 - pathnames / filenames
 - * for scheme

There doesn't appear to be anything that the widget spec allows that can't
be represented with wildcards.

You're right that we don't *need* to support any particular standard. What
we do need, though, is a single format that can be used for all platforms,
so that projects can ship with a single config.xml file.

Is it much work to get BB10 / Tizen to support the "*.example.com" format?


On Fri, Jul 5, 2013 at 3:00 PM, Andrew Grieve <agrieve@chromium.org> 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 <agrieve@chromium.org>
> 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 <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