Re: Opting in to cookies - proposal

On Jun 13, 2008, at 10:45 PM, Jonas Sicking wrote:

> 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.

The downsides of inventing a URI scheme include:

1) URIs using this scheme will not parse into components properly (the  
feed: scheme has this problem)
2) The scheme really should be registered through IANA, which will be  
a bureaucratic hassle
3) IANA would probably be hesitant, because user-private: does not  
describe a new resource access method, it just describes what headers  
you want to send, which in http is separate from the URI
4) It is in fact a valid point that this violates the design of URI  
schemes
5) Code throughout the system will have to know to special-case this  
URI scheme to treat it as equivalent to the corresponding HTTP URI

Compared to that, I think the benefit of retrieving user-specific XSL  
stylesheets with credentials seems pretty low.

In general, even though Access-Control originated as a generic  
mechanism, the XHR use case is clearly far more important to the Web  
than any other and we shouldn't stuff out-of-band parameters in the  
URI just for the sake of the other relatively minor use cases.

>> 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.

So it's just to save a round trip for the cookies case for GET  
requests? (A round trip the first time only since the method check  
result may be cached?)

If you assume opting into cookies is common on the server side, then  
the XHR implementation could send GETs with cookies but deny data and  
retry the request unless the server gives an "I opted into cookies"  
header in the response. If you assume the opposite is more likely then  
you can send the GET without credentials first and retry if the server  
responds that it would have wanted cookies (and you can cache this).

For the common case of XHR, we could also add a separate boolean  
attribute specifying whether the client thinks the server wants  
cookies, to suggest which of the above two guesses to take.

That would work for all cases, with extra requests pretty rare, and  
would not require inventing a URI scheme.


I must say though, this is starting to sound complex and I am not  
totally convinced of the need to make servers opt in to getting  
cookies. Is it really a likely mistake that someone would take  
affirmative steps to enable cross-site access to a per-user resource,  
but then neglect to check whether requests are cross-site and act  
appropriately? And if the administrator of such a server thoughtlessly  
enabled cross-site access without thinking about the consequences,  
would they not be equally likely to enable cross-site cookies without  
thinking about the consequences?

It seems like we are adding a lot of complexity (and therefore more  
opportunity for implementation mistakes) for a marginal reduction in  
the likelihood of server configuration errors.

Regards,
Maciej

Received on Saturday, 14 June 2008 08:39:24 UTC