cordova-dev mailing list archives

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