[Zope-dev] REQUEST.AUTHENTICATED_USER question

[vio]

Thanks for this information, as it provides a big puzzle into my understanding
of how Zope works. As a follow-up to my initial question to this list, namely:
'how do I "login" as user X programmatically, the call seems to be something like:
AccessControl.SecurityManagement.newSecurityManager(None, AccessControl.User.system)
- this will log us in as 'system user' (Zope's equivalent of su). Replacing 
'AccessControl.User.system' with our own string will likely log us as that user.

while the 'logoff' call is:
AccessControl.SecurityManagement.noSecurityManager()

What I still don't understand is why this call is not permanent or 'persistent'?
If I do something like the following inside a class definition:

   AccessControl.SecurityManagement.newSecurityManager(None, 'bozo')
   user1 = SecurityManagement.getSecurityManager().getUser()
   user2 = REQUEST.get('AUTHENTICATED_USER', None)
   return user1,user2

will return 'bozo',bozo'.

But if I call <dtml-var "AUTHENTICATED_USER.getUserName()"> from somewhere else
in my program, I still get 'Anonymous User'. Am I right in concluding that
in order to make my login call 'persistent' I will have to modify the data inside
the cookie which Zope hatches in my browser's nest (where Zope keeps user' 
state)? And that the login call
AccessControl.SecurityManagement.newSecurityManager(None, 'bozo')
is only valid for the duration of a single Zope transaction?

Ok, I'll have a deeper look at exUserFolder, which seems much more complex than
CookieCrumbler (which is why I had chosed to study CookieCrumbler in the first
place).
Thanks for your reply,
Vio

* R. David Murray <bitz@bitdance.com> [020123 12:15]:
> On Mon, 21 Jan 2002, vio wrote:
> > 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 mine.
> 
> 
> > Which to me seems like a lot of overhead. If someone could point me to where
> > 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 problem.
> 
> Zope does not keep a user state anywhere.  For Basic Auth, the
> browser provides the credentials on each transaction.  Cookie
> crumbler of course uses a cookie, which again is provided with each
> transaction by the browser.
> 
> Maybe what you should do is look at the exUserFolder product and
> write your own login methods (and possibly a User Source) against
> that.
> 
> --RDM