- From: Mark S. Miller <erights@google.com>
- Date: Tue, 16 Jun 2009 09:12:14 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: WebApps WG <public-webapps@w3.org>
- Message-ID: <4d2fac900906160912r38f69f03ue85a1fdb5439c431@mail.gmail.com>
On Tue, Jun 16, 2009 at 8:05 AM, Anne van Kesteren <annevk@opera.com> wrote: > > This creates some related issues we have to sort out one way or another: > > A) How does this affect Access-Control-Allow-Origin? > > B) How does this affect the preflight result cache? > I am very glad that the current cors document explains recommended server behavior. Any enhancement, changes, or alternatives to cors should follow this example. If the Origin header expands to carry a list of origins, then we should update the cors recommended server behavior to account for this. Only then can we evaluate what new vulnerabilities we create by adding yet more epicycles. If we cannot write down a coherent recommendation for how servers should make use of this new information, then we should not propose to provide this new information. If cors is indeed on a path to recapitulate the Java stack introspection architecture as Tyler alleges, I would expect the first recommendation to be: Check every origin in the set against the resource's ACL. Only if the ACL allows this access for all origins in the set, then the access is allowed. IIRC, this recapitulates something like Java 1.1 or so. If this is indeed the cors path, the next step on this path would be to allow the redirections to provide additional access control advice, and for the recommended ACL check at the server to treat the list no longer as a set but rather in an order dependent manner, where some of this access control advice cuts off the search farther back in the stack. But perhaps the constraints are different leading to a different trajectory? -- Cheers, --MarkM
Received on Tuesday, 16 June 2009 16:12:50 UTC