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