Re: Users with different access rights in HTTP Authentication

David Morris wrote:
> 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 

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>

> I don't see any legitimate interoperability harmed by a server using 405 
> 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.

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

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

Received on Monday, 23 February 2009 15:03:22 UTC