- From: Bil Corry <bil@corry.biz>
- Date: Wed, 14 Jan 2009 17:45:24 -0600
- To: Adrian Bateman <adrianba@microsoft.com>
- CC: Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>, "public-webapps@w3.org" <public-webapps@w3.org>
Adrian Bateman wrote on 1/14/2009 3:18 PM: > I actually don't think that the generic name is a problem as long as the > CSRF solution uses a different name for a different meaning. The value really > is an Origin and could potentially be used for more than just participation > in the Access Control negotiation. It could still be meaningful in other > scenarios in future which would otherwise now have to define a new header with > the same meaning. I'm thinking out loud here, making sure I have the distinction between the two correct: With Access Control, "Origin" represents the initial request, which survives through a redirect. So as Adrian points out, it really is an "Origin." With CSRF mitigation, "Origin" represents the immediately-preceding request, which for obvious reasons does not survive through a redirect. That's why I liked the idea of just including the chain of requests within Origin, you can then easily find the one you want. But since that isn't on the table, I'm attracted to renaming the CSRF Origin to something like "Request-Origin". Whatever name is chosen, it then has to be added to the XHR spec as a header that can not modified/created via XHR. - Bil
Received on Wednesday, 14 January 2009 23:46:16 UTC