Re: Unauthorized results in 401, shouldn't it result in 403?

On Wed, Apr 20, 2005 at 02:15:30PM +0100, Chris Withers wrote:
| Hi there,
| 
| In Zope auth we have this cool (and I'm being serious here!) idea that 
| authentication and authorisation are seperate things. So I'm confused as 
| to why an authorization failure returns a 401 and not a 403.
| 
| My understanding is as follows:
| 
| 1. anonymous request comes in for url that is not anonymously viewable
| 2. zope replies with a 401 requesting authentication information
| 3. browser supplies previous request but with auth headers
| 4. zope authenticates user (see Sidnei's mail about this part)
| 5. zope authroizes user
| 5.1. auth succeeds, zope publishes object
| 5.2. auth fails, zope returns a 401
| 
| Now, 5.2 is where I have the problem, since raising unauthorized 
| anywhere in Zope traditionally pops up a basic auth box rather than 
| returning standard_error_message with a 403 response which, as time goes 
| by, I'm starting to think is what should really happen.

Yes! That too.

| The only reason I can think for the current behaviour is that it allows 
| you to try another username/password if the current one doesn't have the 
| correct level of authorization. Nowadays, most browsers allow you to 
| drop basic auth headers, and for IE users, they can just fire up a new 
| browser instance.
| 
| Out of interest, CookieCrumbler changes this behaviour by patching 
| things, this is how Plone ends up behaving as I suggest above (although 
| probably not returning a 403 as it should!)
| 
| This all leaves me with a few questions:
| 
| 1. Should things change to work as I describe?

I would think so.

| 2. Is the above behaviour pluggable at all?

Not at all.

| 3. How does PAS handle failover from one authentication plugin to the next?

/me leaves slot for PAS experts to fill

| 4. What kicks off the authentication process in Zope? Something being 
| anonymously viewable or credentials being found in the request?

I've been looking at BaseRequest.traverse(). Basically, it tries to
validate REQUEST._auth, being it set or not *wink* (when using
CookieCrumbler it's this variable is set from the cookie value) and
that may result in a valid user or 'Anonymous User'.

| PS: I suspect the answer to 4 varies depending on the type of auth :-(

I don't think so.

-- 
Sidnei da Silva <[email protected]>
http://awkly.org - dreamcatching :: making your dreams come true
http://www.enfoldsystems.com
http://plone.org/about/team#dreamcatcher

You can't take damsel here now.