Re: [Zope-Coders] Unauthorized results in 401, shouldn't it result in 403?
Sidnei da Silva wrote:
| 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.
| 1. Should things change to work as I describe?
I would think so.
OK, but I would prefer more opinions on this, so moving to zope-dev@zope.org...
| 2. Is the above behaviour pluggable at all?
Not at all.
Should it be? Can it be without impacting on performance?
| 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,
What does? And what does validate mean in this context?
being it set or not *wink* (when using
Right, and that was the source of the other thread?
CookieCrumbler it's this variable is set from the cookie value) and that may result in a valid user or 'Anonymous User'.
Yeah, but how does CookieCrumbler stop a basic auth box being popped to the user when things aren't authorized?
| PS: I suspect the answer to 4 varies depending on the type of auth :-(
I don't think so.
CookieCrumbler vs Everything Else: I think it does... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Wed, Apr 20, 2005 at 04:20:26PM +0100, Chris Withers wrote: | >| 2. Is the above behaviour pluggable at all? | > | >Not at all. | | Should it be? Can it be without impacting on performance? I don't think so. I would expect there's only one sane way to do it. | >| 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, | | What does? And what does validate mean in this context? Did you read what I type? It's in BaseRequest.traverse(). Read the source, I can't summarize 100 lines of python in one sentence. | >being it set or not *wink* (when using | | Right, and that was the source of the other thread? The source of the other thread is that falling back to unauthorized smells wrong, but I can see at least one case where changing this might break existing apps. | >CookieCrumbler it's this variable is set from the cookie value) and | >that may result in a valid user or 'Anonymous User'. | | Yeah, but how does CookieCrumbler stop a basic auth box being popped to | the user when things aren't authorized? Basically it monkeypatches RESPONSE.unauthorized() and RESPONSE._unauthorized(). if not req.get('disable_cookie_login__', 0): if attempt == ATTEMPT_LOGIN or attempt == ATTEMPT_NONE \ or attempt == ATTEMPT_RESUME: # Modify the "unauthorized" response. req._hold(ResponseCleanup(resp)) resp.unauthorized = self.unauthorized resp._unauthorized = self._unauthorized -- Sidnei da Silva <sidnei@awkly.org> http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher Mais sujo que pau de galinheiro.
Sidnei da Silva wrote:
| >| 2. Is the above behaviour pluggable at all? | > | >Not at all. | | Should it be? Can it be without impacting on performance?
I don't think so. I would expect there's only one sane way to do it.
I'm not sure I agree, I've read lots of different views on this sort of thing in these two threads, and I think several of them are valid, while remaining inconsistent with each other. To me, that means it should be pluggable...
The source of the other thread is that falling back to unauthorized smells wrong, but I can see at least one case where changing this might break existing apps.
Yeah, the one Lennart descibes...
Basically it monkeypatches RESPONSE.unauthorized() and RESPONSE._unauthorized().
Aha, as does PAS I see. Does this mean RESPONSE.unauthorized should be a responsibility of the user folder? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 4/21/05, Chris Withers <chris@simplistix.co.uk> wrote:
Aha, as does PAS I see. Does this mean RESPONSE.unauthorized should be a responsibility of the user folder?
I think it should be, yes. Or, actually the responsibility of the user object. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Lennart Regebro wrote:
On 4/21/05, Chris Withers <chris@simplistix.co.uk> wrote:
Aha, as does PAS I see. Does this mean RESPONSE.unauthorized should be a responsibility of the user folder?
I think it should be, yes. Or, actually the responsibility of the user object.
Why the difference? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 2005-04-20 11:20:26 -0400, Chris Withers <chris@simplistix.co.uk> said:
Sidnei da Silva wrote:
| 3. How does PAS handle failover from one authentication plugin to the next?
/me leaves slot for PAS experts to fill
Each attempt at authenticating a particular set of credentials gets a crack, and either stands up for the creds, or returns None.
CookieCrumbler it's this variable is set from the cookie value) and that may result in a valid user or 'Anonymous User'.
Yeah, but how does CookieCrumbler stop a basic auth box being popped to the user when things aren't authorized?
By intercepting the RESPONSE's unauthorized() method. It's pretty plainly there in the code. FWIW, this is how PAS insinuates itself into the process as well, but to allow for any of the challenge plugins to fire this way.
| PS: I suspect the answer to 4 varies depending on the type of auth :-(
I don't think so.
CookieCrumbler vs Everything Else: I think it does...
Well, not in PAS ;^) Zac
participants (4)
-
Chris Withers -
Lennart Regebro -
Sidnei da Silva -
Zachery Bir