W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: Issue 146, was: Users with different access rights in HTTP Authentication

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 21 Jul 2010 15:46:08 -0700
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <5E1572E3-08E0-4232-90F0-A60986D5F978@gbiv.com>
To: Julian Reschke <julian.reschke@gmx.de>
On Jul 21, 2010, at 4:46 AM, Julian Reschke wrote:

> OK, so:
> 
> 401 -> you can't do this because you haven't authenticated

or the credentials are invalid.  Try again only if you can change
the credentials (user login or re-login).

> 403 -> this is forbidden for you, but authenticating as somebody else may help

yep, though forbidden can be broken down into cases:

   a) user agent sent no credentials
       if authentication might help,
          server should respond 401,
       otherwise 403

   b) user agent sent credentials that are invalid or expired
       server should send 401

   c) user agent sent valid credentials but doesn't have access
       server should send 403

> 405 -> this method is not allowed/supported/applicable for this resource

The method you just tried is not allowed for this resource.

   a) user agent sent no credentials
       if authentication might help,
          server should respond 401,
       otherwise 405

   b) user agent sent credentials that are invalid or expired
       server should send 401

   c) user agent sent valid credentials but isn't allowed
       server should send 405

> The use case you mentioned is interesting and came up before: what's a good way to signal to non-authenticated users that authenticating might give access to more operations? "Vary: Authorization" comes to mind. But that still would require the "public" server to know about the "authoring" server, in which case it might be possible to properly return information about method support...

Generally speaking, security folks prefer not to tell clients
about the ways to get in if they are supposed to know that
already.  For example, in role-based access control it is
typical to hide all operations that are not available to the
user, even though the same user can simply change their login
to see them.  The assumption is that there should be other
(application driven) hints that will tell them when to change
their user settings.

Note that this is designed for follow-your-nose (REST-based)
applications.  It doesn't work as well for applications that
think HTTP is a filesystem protocol.

....Roy
Received on Wednesday, 21 July 2010 22:46:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:23 GMT