Hi Vio, By the contents of your message, you seem to be a little off track w.r.t. the way authentication works between the browser and Zope.
By now you seem to have discovered that the browser sends the user credentials whenever it fetches a page. If you aren't using a custom user folder that uses cookies, then you're most likely using basic authentication (which is likely since you don't want the overhead of a product). To know for sure answer this question: when you are anonymous and you want to access a forbiden area, does the browser-standard-login-popup-window shows up? If yes, then there simply is no way you can use "a few placed calls to the Zope machinery" to convince the browser that it needs to switch identities because you're talking to Zope, not to the browser. Zope cannot tell the browser "stop pretending you are anonymous and start pretending you're John". The only thing Zope can tell the browser is "This user you are using is not authorized", in which case the browser will ask the user for another login/password combo, using it's own standard login popup window. On the other hand, if you are using a user-folder product (such as exUserFolder or LoginManager) and it is configured for cookie login, THEN you might be able to change the user "persistently" by changing the cookie. Note, however, that in most cases the cookie contains either a valid user/password combo or a key to a hash table that has the user/password combo. So, in order to tell the browser to pretend to be someone else, you'll probably have to provide the password that goes with the user, which will be impossible if the passwords are stored encrypted. In all cases, it will require knowledge of the format of the cookie that is exclusive to each user-folder and might change in the next version of the user-folder product. As I said, there is no way that "a few placed calls to the Zope machinery" will get what you want, but this is because it is Web, not because it is Zope. Your best bet is still trying to modify an existing, cookie-using, user-folder product, so that you can extend it to have calls that will give you the cookie that you should put in the browser to change the user identity. It's simply TOO HARD to not get involved with user-folders if what you're trying to do deals with user authentication. Cheers, Leo PS: I.M.B.O. (B. as in biased), exUserFolder is the most maleable of them all and the easiest to understand, but it is hard to understand ANY user-folder product if you don't understand Web protocols and/or Zope authentication machinery. On Wed, 2002-01-23 at 19:28, vio wrote: > > [...] all I am looking > for is for the few Zope incantations to 'switch' user identities, > and I can take care of the rest. Now I found how to make this switch, using > AccessControl.SecurityManagement.newSecurityManager(None, myUser) > only this switch doesn't 'persist'. > What is my problem then: at this point, to change the data in the cookie Zope > lays on the browser, so it points to the new 'switched' user. In other words, > make a 'persistent' switch. > > Furthermore, I don't really need an entire product to do this. Just a few well > placed calls to Zope machinery seems to do the trick. > Less overhead as a bonus. -- Ideas don't stay in some minds very long because they don't like solitary confinement. _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )