- From: Marcos Caceres <marcosc@opera.com>
- Date: Tue, 6 Oct 2009 12:42:25 +0200
- To: Phil Archer <phila@w3.org>
- Cc: Scott Wilson <scott.bradley.wilson@gmail.com>, public-webapps WG <public-webapps@w3.org>, Dominique Hazael-Massieux <dom@w3.org>, Marcin Hanclik <Marcin.Hanclik@access-company.com>
On Mon, Oct 5, 2009 at 1:29 PM, Phil Archer <phila@w3.org> wrote: > The problem is finding the right amount of flexibility without making it too > complicated or opening unwanted security holes. right > The beauty of the system proposed by the WAF group way back is that it seems > to achieve this in that: > > example.com - matches all URIs on example.com > and its sub-domains > > *.example.com - matches all sub-domains of example.com > but not example.com itself > > https://example.com - matches all URIs on example.com and its > sub-domains but only when accessed via > https. > > example.com:1234 - matches any URI on example.com, or its > sub-domains, but only when accessed through > the specified port. > > It depends on your use cases of course. For the majority of our uses cases > we want something really simple which was just: > > <includehosts>example.com example.org</includehosts> exactly. > Which is a white space separated list of hosts included in the resource set > (that includes all sub-domains). ok. > POWDER will go further than you need but it means that, using our IRI set > definitions you can define /any/ set of resources no matter how complex or > simple - and you don't need any regexes to do it (although you can use them > too). > What I would *strongly* urge you not to do is to use a URI prefix. That way > lies long lists of domains like http://www.example.com, http://example.com, > http://alice.example.com and so on. *No!* I don't understand the above? Can you please rephrase? > You may also want to consider some form of negation mechanism, i.e. > everything on example.com /except/... Can you elaborate on the use case above? -- Marcos Caceres http://datadriven.com.au
Received on Tuesday, 6 October 2009 10:43:20 UTC