the user folder does this "switch". it's not something you should do
by the way, since replying to your previous email to me bounced back
("[EMAIL PROTECTED]" is unknown) i'm uncluding that here:
i'm not sure what user folder products you were looking at, the
CookieCrumbler is *not* a user folder.
normal user folders do not use BeforeTraverse.
look at the source for the stock user folder
(lib/python/AccessControl.User.py), it is pretty much the simplest
On Monday, January 21, 2002, at 09:23 , [EMAIL PROTECTED] wrote:
But setting the user 'programmatically' is precisely the point of a custom
login method. If I can't set the user programatically inside my code, what'
s the point in a 'custom' login method then? Anyway, I know it'
s feasable, because all the other 'customised' login products are doing
precisely that (after each authenticating the user in their own specific
way). And Zope does it in module HTTPResponse.HTTPResponse.unauthorised()
(called with REQUEST['RESPONSE'].unauthorised()). But I haven't totally
figured it out how that works (how Zope switches user
identities ?????????). And the two 'custom UserFolder' products I've
examined both seem to use ZPublisher.BeforeTraverse to 'make' this switch
happen, somehow. Hence my question to this list: not 'if' the user can be
switched (not 'manually' but 'programmatically'), but 'HOW'!
On Monday, January 21, 2002, at 10:32 , vio wrote:
> The point in a customised login method is precisely to do just that:
> user credentials with some custom scheme. If interested, this is trivial
> to do
> with a valid UserFolder instance around:
> 'if my_custon_loginForm_password ==
> Users_folder.getUser(my_custon_loginForm_loginName)._getPassword(): and
> here SWITCH to the authenticated new user identity'.And Voila! No sweat.
> But I just don't know nor understand how to do that switch
> yet, 'programmatically'.
> * Jens Vagelpohl <[EMAIL PROTECTED]> [020121 09:02]:
>> the user gets modified automatically, provided you use common
>> login-methodology and a user folder that supports it.
> You must be referring to the routine
> called with REQUEST.RESPONSE.unauthorised(). It just happens that I really
> don't like that 'Basic Authentication' dialog, that's why I want to use
> So I've done half of the job to that end, only remaining problem is to
> 'programmatically' to the new authenticated user id. Doing something like
> 'REQUEST['AUTHENTICATED_USER'] = my_custon_loginForm_loginName' seems to
> no effect, because the user is still 'Anonymous User' (found with
> 'AUTHENTICATED_USER.getUserName()'). If only I could understand where
> gets its data for its 'AUTHENTICATED_USER' attribute, I could simply
> that data source, and I'd be done. But I don't still understand how
> gets all the data to its attributes.
>> you don't set the user "manually".
> Of course you do ('programmatically' not 'manually'), as proven by all the
> customised 'login' products out there, who are doing just that.
> Only the one I studied so far
> (CookieCrumbler) seems to re-write the REQUEST.RESPONSE at each traversal.
> Which to me seems like a lot of overhead. If someone could point me to
> Zope keeps user state (I believe with a cookie on the user's browser,
> but where in the source does Zope set this cookie up?),
> I could simply re-write that cookie with the new User ID ... Just a
> thought of a simple and elegant solution (aka 'magic bullet') for my
>> On Monday, January 21, 2002, at 12:35 , vio wrote:
>>> Does anybody know what is the method call to modify the
>>> AUTHENTICATED_USER attribute? I am unable to trace where REQUEST feeds
>>> data for its AUTHENTICATED_USER attribute.
>>> Some context to my question: I am using a custom method to authenticate
>>> users coming to my site. So when the user logs in, he is 'Anonymous
>>> (from call: AUTHENTICATED_USER.getUserName()). But after his login name
>>> and password checked ok, how do I switch his identity in Zope from
>>> 'Anonymous User' to his/her new identity? What I am looking for is that
>>> next time I call 'REQUEST.AUTHENTICATED_USER.getUserName()' to get the
>>> new UserName he just logged in as, not 'Anonymous User' again.
>>> Examining CookieCrumbler.py source, this authentication product uses the
>>> 'before_publishing_traverse hook' mechanism. But isn't there a simpler
>>> way to do this than modifying REQUEST.RESPONSE at each traversal? Sounds
>>> like a lot of overhead.
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -