- From: Mark S. Miller <erights@google.com>
- Date: Mon, 12 Oct 2009 20:24:24 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: "Henry S. Thompson" <ht@inf.ed.ac.uk>, Jonas Sicking <jonas@sicking.cc>, Arthur Barstow <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>
On Sun, Oct 11, 2009 at 11:36 PM, Anne van Kesteren <annevk@opera.com> wrote:
> The concern seems to be mostly about CORS being an access control system.
Yes.
> I'm not entirely sure that is justified (though the headers are indeed
> confusingly named, mea culpa). All CORS does is allowing cross-origin
> resources to communicate with each other. What actions follow from requests
> should in general not follow from (just) the origin were the request
> originated. That would allow all kinds of trouble.
>
> Then again, I think this was explained before as well, so I kind of have the
> feeling we are going around in circles.
The statement that CORS is not an access control system has stopped me
dead before.When I look at the CORS spec I see almost nothing but
access control mechanisms, so I have proceeded to argue access control
specifics under that assumption. I have perhaps been remiss in not
focusing on this issue first, since it may reveal a mutual
misunderstanding. To try to resolve a misunderstanding like this, I
have no choice but to risk belaboring what may indeed be obvious,
since I do not know where the misunderstanding lies. Excuse me if the
following seems pedantic.
As I understand the term, access control is, well, about controlling
access. An access control system enables some entities to control
whether other entities (subjects) are able to access yet other
entities (objects).
Most obviously, CORS proposes ACLs, with comma separated origins
(following an Origin: header) to be used by servers to determine
whether to grant read/PUT/DELETE access to cross-origin resources. The
purpose of CORS is to enable accesses that was previously denied --
exactly such cross-origin access. The purpose of the CORS-proposed
ACLs is to enable those who have the right to edit those ACLs to
control which accesses should be allowed and which should be denied.
The origins serve much the same role as the principle IDs in a
conventional ACL-based access control system.
Likewise, the preflight is intended to deny PUT and DELETE access to
servers that don't know to check the Origin: header. The purpose again
is to allow those accesses we think should be allowed but deny those
we think should be disallowed.
If this is not access control, I must ask: what do you mean by "access control"?
--
Cheers,
--MarkM
Received on Tuesday, 13 October 2009 03:24:59 UTC