- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 12 Jan 2009 17:22:30 -0800
- To: Thomas Roessler <tlr@w3.org>
- CC: public-webapps@w3.org
Thomas Roessler wrote: > On 12 Jan 2009, at 16:31, Jonas Sicking wrote: > >> There are 3 possible solutions that I can see to this: >> 1. Change the name of the Origin header in Access-Control >> 2. Change the name of the Origin header used for CSRF protection >> 3. Change the behavior of one (or both) of the specs such that they >> match in behavior. >> >> My concern with doing 3 is that the CSRF protection part hasn't been >> fully ironed out yet, so if we were to tie Access-Control the the CSRF >> protection scheme then that might leave Access-Control in flux longer >> than we want. > > My preference would be 3. Having two almost identical headers in place > will only cause more confusion, and ultimately do damage. Well, they have semantically different meanings: The Access-Control one means "this is the party I'm sending data to". The CSRF one means "this is the party that initiated the request". But yeah, I agree that it would be great if we could use the same header. My main concern is if it's possible to change implementation at this stage though, I know some implementations are very close to shipping, specifically IE 8. That said, here is a solution that might work for both Access-Control and CSRF protection: Site A makes a request to site B, the UA adds the header "Origin: A" Site B redirects the request to site C, the UA adds the header "Origin: A, B" If the request is an Access-Control request, then in order for site C to authorize the request, it needs to send back "Access-Control-Allow-Origin: A, B". However before even considering this I think we need to check with involved parties that have implementations to see if they will be able to change before shipping. / Jonas
Received on Tuesday, 13 January 2009 01:23:12 UTC