- From: Adam Barth <w3c@adambarth.com>
- Date: Sat, 13 Oct 2012 00:56:35 -0700
- To: Mike West <mkwst@google.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Tanvi Vyas <tanvi@mozilla.com>, dveditz@mozilla.com
On Sat, Oct 13, 2012 at 12:53 AM, Mike West <mkwst@google.com> wrote: > >> On Tue, Sep 25, 2012 at 12:11 AM, Tanvi Vyas <tanvi@mozilla.com> wrote: >>> >>> Perhaps we could distinguish between directories and filenames by looking >>> for a trailing slash followed by a star, so that startup.com has an option >>> to choose between newanalytics.com/js/analytics.js or newanalytics.com/js/*. >> >> >> On the one hand, I like having an explicit wildcard at the end, as it >> makes it quite clear what's meant. On the other, a trailing '/' is probably >> just as explicit, and doesn't get us into weird discussions about supporting >> files named '*'. :) >> >> I'd suggest that: >> * newanalytics.com/js match a file named "js" >> * newanalytics.com/js/ match all files under a directory named "js", and >> * newanalytics.com/js/analytics.js match the specific file "analytics.js" >> under the directory named "js". > > > I've taken a stab at working this into the 1.1 spec, and added a > non-normative section explaining the intent: > https://dvcs.w3.org/hg/content-security-policy/rev/c29f8817f682 > > I found it a bit difficult to formulate, so I'd appreciate some feedback as > to its clarity. In the meantime, I'll get started on an experimental > implementation in WebKit to see if it makes as much sense as I think it > does. :) > > One open question is how we would handle query strings. Do we want to > support 'example.com/js/thisfile.js?id=2'? If so, how would we handle a > request for 'example.com/js/thisfile.js?extra=param&id=2'? Is that a match? > How about 'example.com/js/thisfile.js?id=2&extra=param'? IMHO, we shouldn't support query strings. This feature is most useful for restricting to a known-safe directory. Adam
Received on Saturday, 13 October 2012 07:57:35 UTC