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

[cors] origin and redirects

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 16 Jun 2009 17:05:11 +0200
To: "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.uvmhixlr64w2qv@annevk-t60>
The question has come up again whether Origin should take a space-separated list of origins as to reveal the entire redirect chain. The scenario if I understood it correctly (abarth will hopefully correct me) is as follows:

  A has the following setup:

  Access-Control-Allow-Origin: B-origin
  Access-Control-Allow-Method: DELETE

  C has the following setup due to a compromised
  server:

  Access-Control-Allow-Origin: B-origin
  Location: A-url

  Now B issues a request to C using the method
  DELETE.

There are legitimate reasons for such redirects as well by the way, e.g. if a company moved domains due to renaming, or has been bought by a bigger company and they are integrating their services, etc.

A potential solution to this problem is to include the redirect chain in the Origin header, as follows:

  In the first request (not complicating this
  with preflight requests) it would be:

  Origin: B

  And the subsequent request it would be:

  Origin: B C

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?

(B is interesting nonetheless as apparently since nobody implemented redirects yet and I missed something it is not really clear if it works effectively in face of redirects. *sigh* (Consider a preflight from O to X. X redirects to Y. Y grants O permission. If you now repeat the request to X it will not look in the cache while redirecting to Y. It does not crash and burn either, but it still seems suboptimal.))


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Tuesday, 16 June 2009 15:05:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT