Hi all,
Sorry for the late posting of this, I've been heads down in firefox 3
beta work the past week. Had hoped to get this to you guys well before
mondays meeting, but unfortunately it ended up just being a few hours
before.
What I'm not thrilled about in the current spec, and I think Thomas
touched on this in this thread, is that we're mixing server-side and
client-side authentication when performing non-GET authorization.
On one had we're sending both the requesting domain (in Referer-Root)
and the requested method (in Method-Check?) to the server. This is
enough data for the server to simply send back a yes/no reply.
But then we're letting the server send back both a set of allowed
domains (in Access-Control/<?access-control?>) and a set of allowed
methods (in Allow). This data too would be enough on its own to make a
yes/no decision about if to authorize the non-GET request.
Why do we solve the problem twice?
I have heard arguments that the site might not want to broadcast who it
is authorizing. However this could effectively be figured out still by
simply brute-force testing all interesting servers and methods directly
from an evil server to the target server. No browser involved, simply
send HTTP requests containing Referer-Root and Method-Check headers.
Another thing that occurred to me is does HTTP caches take the full set
of request headers into account when caching? Otherwise it could be
directly harmful to include Referer-Root and Method-Check headers. The
cache might store an "authorize" reply when the request is made for
Referer-Root A and wrongly respond with the same document is checked for
Referer-Root B.
/ Jonas
Anne van Kesteren wrote:
On Wed, 31 Oct 2007 16:59:43 +0100, Thomas Roessler <[EMAIL PROTECTED]> wrote:
On 2007-10-31 16:26:38 +0100, Anne van Kesteren wrote:
XMLHttpRequest POST allows more than <form> POST.
Please elaborate.
The scenario was doing cross-site XML POST as that might hurt SOAP
servers. I seem to recall someone saying this is possible with <form>
POST as well though I'm not sure exactly how, but only with
XMLHttpRequest the Content-Type header would be an XML MIME type.
Servers will have to deal with cross-site <form> POST, but
probably don't deal with cross-site XMLHttpRequest POST. As such,
XMLHttpRequest POST is not guaranteed to be as "safe" as
cross-site <form> POST is.
Please explain the differences from the perspective of the site that
needs to handle these requests, and explain how they are relevant
for the discussion at hand.
<form> POST is not relevant to the discussion at hand. XMLHttpRequest
POST follows the model with Method-Check, etc.
Also, this makes it work for arbitrary method names, not just POST.
Fair point. One question is, then, whether cross-site XHR
should be limited to GET and POST.
It should not.
Method-Check is done by the client.
The If-Method-Allowed (or Method-Check) header is *set* by the
client. That presumably happens so the server can evaluate it and
do something interesting. If you don't expect any server-side
processing, please drop the header.
If the server gets that header it knows this is an authentication
request and can give an appropriate reply.
Allow is done by the server.
Allow is set by the server, yes, and becomes part of the client's
decision. That actually adds new meaning to this header; we might
want to check the interaction with possible other uses.
If that's the case we can simply introduce a new header. Although
"simply" I believe Firefox might be shipping soonish :-(
Non-GET requests are indeed more difficult, but since non-GET is
already more complicated than just sending a reply (you have to
do some more "advanced" processing on the server as a result of
the request) I don't see this as a problem.
The main use case here is POST, which is deployed in existing
servers. The additional header needs to be dealt with when it
occurs on a GET request.
Requiring special server-side processing for an existing method
means a significant change in terms of deployment scenario.
Well, you'd have a single resource on the server I assume that takes
care of both the GET and POST responses. My point was that if the author
of the server is going to handle POST he/she already needs to do a
certain amount of coding rather than just putting a data source online.
Handling the additional request isn't that more complicated than.
In particular, with the current model, and currently-deployed
servers, if a GET request for a resource returns an XML document
that includes an access-control processing instruction, then any
policy included in that document will spill over to permitting POST
requests for the same resource; mitigating that requires a change to
server behavior.
No, because such content would not include an Allow HTTP header
that allows that.
With the currently-specified use of the Allow header, such content
could include that header. See RFC 2616, section 14.7.
Ok, but that content wouldn't have Access-Control/<?access-control?>.
Meanwhile, we also have a Referer-Root header of which we don't
say what it is supposed to mean or do.
It allows you to not expose all the sites you make your content
available to by just emitting the value from the Referer-Root
header if you indeed allow that site.
So this is the second HTTP header that we expect to influence the
result of a GET request that isn't really a GET request?
My magic eight ball says yes.
This is what using Allow solves. It has been suggested to use a
new HTTP header for that purpose in case some servers have this
header by default. Given that you also need
Access-Control/<?access-control?> I'm not sure if that's really
worth it, but I'm open to feedback that suggests otherwise.
See above; the combination of Allow's current definition and the
processing instruction makes this a nasty trap.
As far as I can tell it's only used for OPTIONS requests, but ok. What
do other people think?
I hope the above clarifies the ideas.
It clarifies some of the ideas, but it doesn't make the current spec
good.
The current spec doesn't reflect the ideas.
I also hope to find some time soonish to rewrite the draft.
Maybe wait with that till we're through this discussion. ;-)
So far the only potential change is renaming the Allow header. But sure,
I can wait.
