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
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.
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
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
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -