Re: Design issues for access-control

On Wed, 31 Oct 2007 16:59:43 +0100, Thomas Roessler <tlr@w3.org> 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.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Wednesday, 31 October 2007 16:11:39 UTC