On Mon, 21 May 2007 16:47:11 +0200, Tim Berners-Lee <[EMAIL PROTECTED]> 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:
http://dev.w3.org/cvsweb/~checkout~/2006/waf/access-control/Overview.html?content-type=text/html;%20charset=utf-8
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:
http://dev.w3.org/cvsweb/~checkout~/2006/waf/access-control/Overview.html?content-type=text/html;%20charset=utf-8#match
(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
<http://annevankesteren.nl/>
<http://www.opera.com/>
