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
