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
if not req.get('disable_cookie_login__', 0):
if attempt == ATTEMPT_LOGIN or attempt == ATTEMPT_NONE \
or attempt == ATTEMPT_RESUME:
# Modify the "unauthorized" response.
resp.unauthorized = self.unauthorized
resp._unauthorized = self._unauthorized
Sidnei da Silva <[EMAIL PROTECTED]>
http://awkly.org - dreamcatching :: making your dreams come true
Mais sujo que pau de galinheiro.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -