cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: Cordova 3 Whitelist -- now with significantly less magic!
Date Fri, 30 Aug 2013 15:28:51 GMT
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