Re: XHR without user credentials

Thanks Tyler.  I understand your use case now.  I don't see the harm
in sending Origin: null, so I haven't changed the I-D, which requires
a (possibly null) Origin header in some cases.

Adam


On Tue, Jun 9, 2009 at 11:50 AM, Tyler Close<tyler.close@gmail.com> wrote:
> On Tue, Jun 9, 2009 at 11:19 AM, Adam Barth<w3c@adambarth.com> wrote:
>> On Tue, Jun 9, 2009 at 9:38 AM, Tyler Close<tyler.close@gmail.com> wrote:
>>> On Tue, Jun 9, 2009 at 9:29 AM, Adam Barth<w3c@adambarth.com> wrote:
>>>>  Isn't the whole
>>>> point of this feature to be able to distinguish guest and non-guest?
>>>
>>> So requests from XMLHttpRequest have an Origin header, and requests
>>> from GuestXMLHttpRequest don't. The server should treat requests
>>> coming from GuestXMLHttpRequest as bits arriving from an unknown
>>> client (ie: a "guest"), and so only authorize them based on
>>> information explicitly included in the request.
>>
>> Given an HTTP request, what algorithm should the server use to
>> determine whether the request was generated by GuestXMLHttpRequest?
>
> That's not the question the server wants to answer. The question is:
> How should the server treat any cookies (or other browser added
> credentials) in the request.
>
> 1) There is an Origin header: Treat any user credentials as indicated
> by the CORS spec for XMLHttpRequest.
>
> 2) There is no Origin header:
> a) request from legacy browser: If there are credentials in the
> request, use these as indicated by whatever CSRF defense you are
> using.
> b) request from non-browser client: If there are credentials in the
> request, the client has direct knowledge of them. They did not come
> from the browser's ambient environment.
> c) request from GuestXMLHttpRequest: There are no credentials in the request.
>
> The sub-cases of 2) collapse into: Treat any credentials in the
> request as you do today, guarded by whatever CSRF defenses you use.
>
> From the perspective of your Origin work, requests from
> GuestXMLHttpRequest are like requests from a non-browser client, and
> so don't have a reliable Origin header value.
>
> --Tyler
>
> --
> "Waterken News: Capability security on the Web"
> http://waterken.sourceforge.net/recent.html
>

Received on Tuesday, 9 June 2009 19:02:31 UTC