- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 27 Mar 2007 14:49:29 +0200
- To: "WAF WG (public)" <public-appformats@w3.org>
Hi, 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. Cheers, -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Tuesday, 27 March 2007 12:50:20 UTC