Subject: Re: Users with different access rights in HTTP Authentication

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Feb 2009 14:25:52 +0100

...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.

Best regards, Julian

---

From: David Morris <[email-masked]>
Date: Mon, 23 Feb 2009 06:35:45 -0800 (PST)

On Mon, 23 Feb 2009, Julian Reschke wrote:

>>>> header the methods that this particular authenticated user is allowed to 
>>>> perform. (i.e. Allow: GET)
>>> 
>>> "The Allow entity-header field lists the set of methods supported by the 
>>> resource identified by the Request-URI." -- 
>> 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.)
>> 
>> this, for example by displaying a "Read-only" indicator and disabling the 
>> "Save" button.
>> ...
>
> 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". -- 

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Feb 2009 16:02:38 +0100

David Morris wrote:
> who the user is. That request is NOT ALLOWED for THAT USER. Telling user 

For this use case, we already have the status code 403. People 
apparently are confused whether to use 405 or 403, so I think the spec 
needs to be improved.

> 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.

Yes. That's a potential feature.

Servers are always free to hide these details from a user, though. For 
instance, many servers return 404 if the authenticated user has not read 
permissions, but the resource indeed is there:

"10.4.4 403 Forbidden

The server understood the request, but is refusing to fulfill it. 
Authorization will not help and the request SHOULD NOT be repeated. If 
the request method was not HEAD and the server wishes to make public why 
the request has not been fulfilled, it SHOULD describe the reason for 
the refusal in the entity. If the server does not wish to make this 
information available to the client, the status code 404 (Not Found) can 
be used instead." -- 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.4.4>

> to mean YOU or ALL OF YOU.

The problem is in the coupling between status code 405, and the 
definition of the "Allow" header. That one talks about "supported", 
which, as far as I can tell, is a different concept from being "allowed" 
to do something.

> 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.

Again, people are confused about whether to pick 403 or 405 if the 
authenticated user does not have the necessary privileges to execute a 
method. That is an issue.

We can either tell them to pick 403 (which I think is the intent of RFC 
2616, and also is widely used that way), or we can leave things open (in 
which case we should state *that*).

BR, Julian