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 <iclell...@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 <iclell...@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 > > >
