cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Cordova 3 Whitelist -- now with significantly less magic!
Date Sun, 01 Sep 2013 03:11:20 GMT
That was the case I was going for (private IP access only). Don't know of
any other type of IP wildcard cases


On Fri, Aug 30, 2013 at 11:28 PM, Ian Clelland <iclelland@chromium.org>wrote:

> There is one other feature that we have dropped support for, and it's the
> one that is the hardest to justify, except to say "it's just not in the
> spec": Wildcards in IP addresses.
>
> Previously, a whitelist spec like "http://192.168.0.*/*" was valid, and
> would match the entire subnet. This has been removed, and wildcards in a
> hostname position are only valid as the first component.
>
> This was never documented, but was tested and working before.
>
> Do we have any idea whether this feature is in actual use? The best use
> case I can see for it is for private networks, where a developer's machine
> might have an ip that changes daily, and no DNS name.
>
> Larger organizations *do* own large public IP address blocks, but they also
> generally have control over their DNS, and can assign proper names to any
> services which should be used by an app.
>
> Additionally, the class-A/B/C address allocation that is roughly suggested
> by these wildcards isn't in wide use anymore, and hasn't been for some
> time. It is much more common for an organization to control, say, a /28
> address block (which can't be represented with wildcards) than an entire
> class C, or for orgs to need something larger, (which would necessitate
> many whitelist entries).
>
> I've started a separate thread on the chromium lists about the usefulness
> of this feature, but I'm curious whether there is any actual use
> in-the-wild by Cordova apps.
>
> Ian
>
>
> On Fri, Aug 30, 2013 at 11:00 AM, Ian Clelland <iclelland@chromium.org
> >wrote:
>
> > Following up on the 700+ unit test failures reported this morning, I've
> > gone and cleaned up the iOS whitelist unit tests.
> >
> > iOS had always had some crazy whitelist handling "features", but the full
> > crazy was never completely documented. Our new whitelist roughly follows
> > the spec at http://developer.chrome.com/apps/match_patterns.html, and
> > drops some of the features previously supported.
> >
> > To be explicit (and generate discussion where needed,) these features
> have
> > been changed / removed for iOS since Cordova 2.9:
> >
> > 1. There is no more magic TLD matching: You cannot specify "apache.*" and
> > have it match "apache.us", "apache.ca", "apache.gl", "apache.aero",
> > "apache.xxx", etc. This feature had some problems; it matches all
> 2-letter
> > ccTLDs, but does not match useful domains like "apache.ac.uk", "
> > apache.co.jp", etc. It had a hard-coded list of longer TLDs which needed
> > to be updated in sync with the ICANN list. And it would always leave an
> app
> > in a vulnerable position unless you were willing to purchase domain
> rights
> > in every conceivable jurisdiction.
> >
> > 2. There is less magic protocol/scheme handling: "apache.org" should be
> > equivalent to "*://apache.org", and matches http://apache.org and
> > https://apache.org (by the spec). "*" matches *all* urls. If you need
> > only "http[s]://*" and "ftp[s]://*", then just put those four patterns in
> > your whitelist.
> >
> > 3. No crazy wildcards. Wildcards are permitted at the start of a host, at
> > the end of a path, or as the scheme. Patterns like "ht*p://*.ap*he.o*g/"
> > aren't recognized any more.
> >
> > 4. The whitelist mechanism tests against whole urls, rather than
> > fragments. This means that you can test whether "http://www.apache.org/"
> > matches your current whitelist, but if you try to test "apache.org", or
> > even "http://www.apache.org", then those will fail. They aren't complete
> > URLs, and so should never be generated as a link target or XHR source
> > anyway. (Adding the trailing "/" is really a browser feature, just for
> > typing URLs in the address bar anway. Apps will almost always be working
> > with complete URLs.)
> >
> > Ian
> >
>

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