Re: Cordova 3 Whitelist -- now with significantly less magic!

[Shazron <sh...@gmail.com>]

+1 for consistency


On Fri, Aug 30, 2013 at 11:00 PM, Ian Clelland <ic...@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
>