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
