W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [cors] origin and redirects

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 17 Jun 2009 15:40:43 +0200
To: "Mark S. Miller" <erights@google.com>
Cc: "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.uvn795ui64w2qv@annevk-t60>
On Tue, 16 Jun 2009 18:12:14 +0200, Mark S. Miller <erights@google.com> wrote:
> 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.

Yeah, I do not think this is the problem though. Although it does increase complexity. Not sure if it increases it significantly, but comparing a list is certainly more complex than a string.

> 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?

I'm not sure. I'm hoping for people smarter than me to figure this one out :-)

Anne van Kesteren
Received on Wednesday, 17 June 2009 13:41:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC