Re: [WARP] "uri" attribute is confusing

The problem is finding the right amount of flexibility without making it 
too complicated or opening unwanted security holes.

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>

Which is a white space separated list of hosts included in the resource 
set (that includes all sub-domains).

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!*

You may also want to consider some form of negation mechanism, i.e. 
everything on example.com /except/...

HTH

Phil.

Scott Wilson wrote:
> I agree that "pattern" implies that you could use regular expressions 
> (or similar) - this would be a much more flexible way to handle access, 
> but does have implications (e.g. no need for a 'subdomains' attribute).
> 
> In our system we will be using the access element to prompt the server 
> admin to add entries to a whitelist for a proxy server - in this case a 
> person is in the loop, and so its unlikely that anything nasty would be 
> accepted. However in more automated cases I agree with  Marcin there 
> would be complex security issues to address.
> 
> RE does however have the benefit of being very well known, with plenty 
> of good implementations, and understood by developers (including those 
> handling security issues).
> 
> S
> 
> On 1 Oct 2009, at 22:13, Marcin Hanclik wrote:
> 
>> Hi Dom, All,
>>
>> I am not convinced by the need to include the word "pattern" in the 
>> name of the attribute taken the current WARP text.
>> Specifically because the semantics of the value of the attribute is 
>> more like namespace or just the leading part of the URI.
>> Pattern would be ok, if e.g. we would use regular expression or 
>> similar construct in the value of the attribute.
>>
>> On the other hand, I think that having some pattern mechanism (like 
>> e.g. regular expression) would help in having better semantics of the 
>> functionality currently proposed behind <access> element.
>> The recent need to handle local network [1] could be probably 
>> satisfied based on regular expression / pattern for IP address in HTTP 
>> URI (related to the issue with subdomains as in [2]).
>> The private IP address ranges [3] could be then possibly fine-tuned if 
>> required by the application.
>> Pattern mechanism could nicely complement (or maybe replace to some 
>> extent?) my proposal from [2], however, we would risk it being too 
>> complex (maybe very good for Perl people, but could blur the actual 
>> value for an average RE reader; so we may discard this RE idea, 
>> specifically because the security model should not be too complex IMHO 
>> in order to be widely and successfully deployed).
>> I assume that some pattern mechanism could be discussed in the light 
>> of the recent comments on WARP and proposal to use POWDER (a bit too 
>> rich also IMHO, but maybe some subset could be adopted).
>>
>> Thanks,
>> Marcin
>>
>> [1] 
>> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0011.html
>> [2] 
>> http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0844.html
>> [3] http://tools.ietf.org/html/rfc1918
>>
>> ________________________________________
>> From: public-webapps-request@w3.org [public-webapps-request@w3.org] On 
>> Behalf Of Dominique Hazael-Massieux [dom@w3.org]
>> Sent: Wednesday, September 23, 2009 3:19 PM
>> To: public-webapps@w3.org
>> Cc: phila@w3.org
>> Subject: [WARP] "uri" attribute is confusing
>>
>> Hi,
>>
>> The attribute "uri" on the <access> element in WARP is somewhat
>> misleading - what it takes is more a URL pattern than a URI. I would
>> suggest renaming it in "urlpattern" or just "pattern" (unless there are
>> already many implementations that rely on that attribute name).
>>
>> There may be lessons to be taken in designing these patterns from POWDER
>> http://www.w3.org/TR/2009/REC-powder-dr-20090901/ - although I suspect
>> the POWDER expressivity needs are much greater than what is needed here.
>>
>> Dom
>>
>>
>>
>>
>> ________________________________________
>>
>> Access Systems Germany GmbH
>> Essener Strasse 5  |  D-46047 Oberhausen
>> HRB 13548 Amtsgericht Duisburg
>> Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
>>
>> www.access-company.com
>>
>> CONFIDENTIALITY NOTICE
>> This e-mail and any attachments hereto may contain information that is 
>> privileged or confidential, and is intended for use only by the
>> individual or entity to which it is addressed. Any disclosure, copying 
>> or distribution of the information by anyone else is strictly prohibited.
>> If you have received this document in error, please notify us promptly 
>> by responding to this e-mail. Thank you.
>>
> 

-- 


Phil Archer
W3C Mobile Web Initiative
http://www.w3.org/Mobile

http://philarcher.org

Received on Monday, 5 October 2009 11:30:25 UTC