Below the same message without the silly line endings. Sorry about that.
On Tue, 27 Mar 2007 14:49:29 +0200, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
[...]
The current algorithm for access control is that a resource has an
associated list two-tuples. Each two-tuple consits of one list with at
least one item, the allow list. And another list which may be empty, the
exception list. When a request is made to a resource to which the access
control read policy applies you go through each of the two-tuples and as
soon as you reach one where one of the items in the allow list matches
with the request URL and the exception list (in the same two-tuple) does
not access is granted and the access algorithm aborted. Otherwise access
is denied.
This means for instance that a request from foo.bar.com would get access
in this case:
[([*.bar.com], [foo.bar.com])
,([*.bar.com], [])]
The two-tuples are formed by HTTP Content-Access-Control header rules and
<?access-control?> processing instructions. Each of them creates one
two-tuple.
The advantages of this proposal are that each header rule and each
processing instruction contributes one item which is individually
analyzed. It's not really clear why this is needed or desirable though
especially as it also allows scenarios as pointed out above. The main
problem with this approach is that it's quite complex to grasp and so far
nobody really got it I believe.
The other idea which was specified initially is that all rules specified
by HTTP headers and processing instructions are combined into two global
lists. One list of allow rules and one list of exceptions to those allow
rules. (The latter could probably be called "deny" as it would be
effectively the same.)
The algorithm for this would be that once both lists are constructed you
first match the request URL against the items in the allow list and if
there's match and there's no match in the exception / deny list you grant
access. Otherwise access is denied. (Assuming that the access control read
policy is applicable to the requested resource.
Personally I'm in favor of the second proposal as I think it addresses the
same usecases and has less surprises and complexity. It would be good if
authors and implementors commented on this approach.
If needed I'm willing to discuss this during the groups telcon if anybody
sees some advantage in doing that.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
