Re: Opting in to cookies - proposal

Maciej Stachowiak wrote:
> 
> 
> On Jun 13, 2008, at 5:20 PM, Jonas Sicking wrote:
> 
>>
>> Maciej Stachowiak wrote:
>>> On Jun 13, 2008, at 4:56 PM, Jonas Sicking wrote:
>>>>
>>>> Hi All,
>>>>
>>>> Since I haven't received any feedback on the various straw-men in 
>>>> the "Opting in to cookies" thread, I'll send a full proposal (wrote 
>>>> most of this yesterday, Thomas wrote some opinions on cookies this 
>>>> morning).
>>>>
>>>> First off, as before, when I talk about "cookies" in this mail I really
>>>> mean cookies + digest auth headers + any other headers that carry the
>>>> users credentials to a site. However i'll just use the term "cookies"
>>>> for readability, and since that is on the web currently the most
>>>> common carrier of credentials.
>>>>
>>>> So here goes:
>>>>
>>>> When loading a resource using access-control associate the request with
>>>> a "with credentials" flag.
>>>>
>>>> When the resource is loaded using an URI which starts with the string
>>>> "user-private:" set the "with credentials" flag to true. Otherwise set
>>>> it to false.
>>> How could an http or https URI start with the string "user-private:"? 
>>> Are you proposing a new URI scheme?
>>
>> My proposal is for nesting schemes, so you'd load 
>> user-private:http://example.com/address.php
> 
> That strikes me as distasteful. I would prefer to see a separate 
> includeCrossSiteCredentials parameter on XHR somewhere than to use 
> in-band signalling via the URL, if we feel this is needed.

The advantage with putting it as part of the URI is that it is agnostic
to which method used for loading. So for example inside XSLT you could do:

<xsl:for-each
   select="document('user-private:http://example.com/adr')/adr/*">
   Name <xsl:value-of select="@name">
</xsl:for-each>

to incorporate private data. This is one of the design goals of
Access-Control, that it is a generic loading mechanism, rather than
limited to a particular API.

> However, I am not sure I understand the purpose of extra client-side 
> opt-in to cookies. Presumably the client side is cross-site and 
> therefore not under control of the server. So if the server is careless 
> about cross-site requests that include cookies or other credentials, 
> then I do not see how an opt-in mechanism on the client side helps at all.

The opt-in ultimately comes from the server through the
Access-Control-With-Credentials header. However for GET requests we 
don't know if the server is going to opt in or not at the time when the 
request is made. Therefore the client must opt in first, however if the 
client opts in but the server doesn't, the response from the server is 
discarded.

/ Jonas

Received on Saturday, 14 June 2008 05:47:07 UTC