- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 16 Jan 2008 23:22:59 +0000 (UTC)
- To: Thomas Roessler <tlr@w3.org>
- Cc: public-appformats@w3.org
On Thu, 17 Jan 2008, Thomas Roessler wrote: > > One problem with the pre-flight check is that it is not bound to the > subsequent requests that it might authorize. > > This means that there are race conditions when policies change, as the > service is unable to distinguish requests that were authorized before a > policy change from requests that were authorized afterwards. Actually it turns out that isn't a problem, because the server can just re-do the security check on the actual request. (In fact in the extreme it could just automatically reply "allow *" for all OPTIONS requests, and then make the actual determination in the real POST/DELETE/etc requests.) The reason for the preflight isn't for servers going forward, it's just to make sure that existing servers aren't exposed to cross-site request forgery attacks using APIs that rely on Access-Control. > It also means that a service that is intended to expose data across > origins can't distinguish between a request that's caused through some > XSRF technique, and one that has gone through the authorization > algorithm. Again, it doesn't need to, as it can just do the authorization step on the request itself, either instead of, or as well as, on the OPTIONS preflight request. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 16 January 2008 23:23:14 UTC