Re: Users with different access rights in HTTP Authentication

Is this just a matter of s/allowed/supported/ in the definition of 405?


On 24/02/2009, at 1:35 AM, David Morris wrote:

>
>
> On Mon, 23 Feb 2009, Julian Reschke wrote:
>
>> ...following up from a discussion on www-talk:
>>
>> Martin Atkins wrote:
>>> Julian Reschke wrote:
>>>>> * Return 405 Method Not Allowed, and indicate in the "Allow"  
>>>>> response header the methods that this particular authenticated  
>>>>> user is allowed to perform. (i.e. Allow: GET)
>>>> The description for 405 is not very clear, but the one for  
>>>> "Allow" is (IMHO):
>>>> "The Allow entity-header field lists the set of methods supported  
>>>> by the resource identified by the Request-URI." -- <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7 
>>>> >
>>>> So no, this doesn't fit.
>>> So I guess the thought here is that the text says "methods  
>>> supported" rather than "methods allowed", which implies that it is  
>>> not user-sensitive.
>>> If Allow is not supposed to reflect the access rights of the  
>>> remote user, can you suggest an alternative mechanism by which I  
>>> can tell the client "You can GET but you don't have access to PUT  
>>> or DELETE?"
>>> (Currently I'm using "Allow" for this, but now that you've called  
>>> out that specific sentence I agree that it does not seem to be  
>>> intended to reflect access rights.)
>>> The need is letting user-agents that retrieve the resource know  
>>> ahead of time that a PUT or DELETE will not be allowed so that the  
>>> UI can reflect this, for example by displaying a "Read-only"  
>>> indicator and disabling the "Save" button.
>>> ...
>>
>> Part 2 currently says about status 405:
>>
>> "8.4.6 405 Method Not Allowed
>>
>> The method specified in the Request-Line is not allowed for the  
>> resource identified by the request-target. The response MUST  
>> include an Allow header containing a list of valid methods for the  
>> requested resource."
>>
>> Martin is not the first one to read this as "the authenticated user  
>> is not allowed to, but somebody else might". -- <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-05.html#rfc.section.9.4.6 
>> >
>>
>> But this is not what the description of the related "Allow" header  
>> implies:
>>
>> "10.1 Allow
>>
>> The response-header field "Allow" lists the set of methods  
>> advertised as supported by the resource identified by the Request- 
>> URI..." -- <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-05.html#rfc.section.10.1 
>> >
>>
>> ...which makes it matter of being supported by the resource in  
>> general.
>>
>> We probably should clarify this in the description of status 405.
>
> I don't see a reason why it matters except in the context in which  
> the request is issued. That context may include some form of  
> knowledge about who the user is. That request is NOT ALLOWED for  
> THAT USER. Telling user A that a request is allowed for some OTHER  
> USER just invites an attempt by user A to become authorized as if  
> they are USER B.
>
> I don't see any legitimate interoperability harmed by a server using  
> 405 to mean YOU or ALL OF YOU.
>
> I don't see it as a legitimate objective of the HTTP protocol to let  
> EVERYONE learn what YOU are allowed to do.
>
> And reading the two cited sections, I see no conflict. "Methods  
> advertised" can be contextual w.r.t. the specific user context, if  
> the server so chooses OR it can apply to all users. I see no  
> underlying reason to make a change to avoid this flexibility and I  
> don't see any lack of clarity which requires expanding the final  
> document.
>
> David Morris
>


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 8 April 2009 06:43:35 UTC