W3C home > Mailing lists > Public > public-appformats@w3.org > May 2007

Re: No path in access item, etc.

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 21 May 2007 16:53:46 +0200
To: "Tim Berners-Lee" <timbl@w3.org>, public-appformats@w3.org
Message-ID: <op.tsombwxt64w2qv@annevk.hotspot.sfr.fr>

On Mon, 21 May 2007 16:47:11 +0200, Tim Berners-Lee <timbl@w3.org> wrote:
> Reviewing http://www.w3.org/TR/access-control/
> http://www.w3.org/TR/2007/WD-access-control-20070215/

Please take a look at the far more recent editor draft:


> 1. The term "request URI" is a confusing term for the URI of the source  
> making the request, when the HTTP request has a URI in it which is the  
> requested URI. It isn't the URI of the requesting client, either.     
> Suggest: codebase URI?  This is like 'codebase principals' in existing  
> security models.

I'll look into this when updating the document.

> 2. The inability to specify a path as an access item is a problem.
> For example, there is a lot of stuff I wouldn't vouch for on, for  
> example,  www.w3.org, or on csail.mit.edu, but specific paths which I  
> would trust more.   A path prefix is needed. Why was it omitted.

It is omitted because you the "codebase URI" can "fake" the path already  
by opening another document on the same domain in an iframe and initiating  
the request from there. This is basically coming down from the defacto web  
security model.

> 3. When implementing the access system, restricting access items to be  
> (with domain fields reversed) prefixes would make matching easy and  
> fast. (You can  order the prefixes, and quickly find the match in a long  
> list. Not that you have long lists in the examples, but I'd note that  
> this sort fo stuff may get picked up by all kinds of other specs.)
> http://*.example.com/   becomes a prefix http://com.example.
> http://www.w23.org/2007/safescripts/* is just  http://www.w23.org/ 
> 2007/safescripts
> The constraint means you can't have http://*.example.com/fred/* as there  
> are wildcards at two levels separated by a constant.
> I feel it is wise to keep the matching really simple, rather than (say)  
> regexps.

The matching should be simpler now. See:


> (I'm sorry the domain name fields are the way they are, that is a bug we  
> have to work around :-/ )

Heh :-)

Thanks for your comments!

Anne van Kesteren
Received on Monday, 21 May 2007 14:53:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:07 UTC