become user (su inside Zope) - pretend to be another user
I need to save and then "replay" web requests at a later time on behalf of an authenticated user, then email them the result. We use LDAPUserFolder and the user's passwords are encrypted, so I can't just lookup a user's password and feed it back to a web request using basic auth. of course I have "super user" access to the zope instance (2.7.0), is there any tricks I can play that will "su" inside a zope request context to become another user and set the AUTHENTICATED_USER roles correctly? I'm looking for an official mechanism to do this, rather than hacking up my user folder. Any ideas? -- Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements
You can do the following (in an ExternalMethod): from AccessControl.SecurityManagement import newSecurityManager uf = self.acl_users user = uf.getUserById('blah').__of__(uf) newSecurityManager(None, user) # You are now logged in as user 'blah' Stefan --On Donnerstag, 23. Oktober 2003 15:14 -0400 Brad Clements <bkc@murkworks.com> wrote:
I need to save and then "replay" web requests at a later time on behalf of an authenticated user, then email them the result.
-- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/
Thanks for this tip, interestingly that's open exactly what I had come up with, thanks for the confirmation: I looked at newSecurityManager and it doesn't seem to set request.AUTHENTICATED_USERS, so I do that too. dn = "cn=dr,ou=sfiusa,ou=Public,dc=zyx,dc=com" def test(request, context): """test stuff""" uf = context.acl_users u = uf.getUserByDN(dn) if u is None: raise RuntimeError() newSecurityManager(None, u) request.AUTHENTICATED_USER = u On 23 Oct 2003 at 23:02, Stefan H. Holek wrote: Date sent: Thu, 23 Oct 2003 23:02:51 +0200 From: "Stefan H. Holek" <stefan@epy.co.at> To: bkc@murkworks.com Copies to: zope@zope.org Subject: Re: [Zope] become user (su inside Zope) - pretend to be another user
You can do the following (in an ExternalMethod):
from AccessControl.SecurityManagement import newSecurityManager
uf = self.acl_users user = uf.getUserById('blah').__of__(uf) newSecurityManager(None, user) # You are now logged in as user 'blah'
Stefan
--On Donnerstag, 23. Oktober 2003 15:14 -0400 Brad Clements <bkc@murkworks.com> wrote:
I need to save and then "replay" web requests at a later time on behalf of an authenticated user, then email them the result.
-- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/
-- Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements
Why is everybody so obsessed with AUTHENTICATED_USER? This variable is not suitable for anything deserving the name "security". It is NOT SAFE to assume that it will contain anything useful. This is even documented in the online help: SecurityGetUser() -- Return the current user object. This is normally the same as the 'REQUEST.AUTHENTICATED_USER' object. However, the 'AUTHENTICATED_USER' object is insecure since it can be replaced. To get the logged-in user call: SecurityGetUser() or getSecurityManager().getUser() or portal_membership.getAuthenticatedMember() and please forget about AUTHENTICATED_USER and the REQUEST as a source of trustable information in general. Stefan --On Donnerstag, 23. Oktober 2003 19:52 -0400 Brad Clements <bkc@murkworks.com> wrote:
I looked at newSecurityManager and it doesn't seem to set request.AUTHENTICATED_USERS, so I do that too.
-- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/
Why is everybody so obsessed with AUTHENTICATED_USER? This variable is not suitable for anything deserving the name "security". It is NOT SAFE to assume that it will contain anything useful.
Amen to that. jens
Jens Vagelpohl wrote:
Why is everybody so obsessed with AUTHENTICATED_USER? This variable is not suitable for anything deserving the name "security". It is NOT SAFE to assume that it will contain anything useful.
Amen to that.
jens
Right, when can we consider REQUEST to be fairly safe? I.e. I know that it cab be manuoulated by any kind of script during the lifetime of a request, and aslo be populated from the URL. I consider manipulation from scripts acceptable behaviour, from the URL not. What I am actually trying to say is the following: I need a secure namespace available, a` la REQUEST, during the lifetime of a request - lets call it SAFE_REQUEST, that cannot be manipulated from the URL. Preferrably RAM-bound. Any ideas on how to achieve that (other than reading source, which I allready have begun to). Thanks, /dario -- -- ------------------------------------------------------------------- Dario Lopez-Ka"sten, IT Systems & Services Chalmers University of Tech.
On Fri, 24 Oct 2003 18:20:02 +0200 Dario Lopez-Kästen <dario@ita.chalmers.se> wrote:
Jens Vagelpohl wrote:
Why is everybody so obsessed with AUTHENTICATED_USER? This variable is > not suitable for anything deserving the name "security". It is NOT > SAFE to assume that it will contain anything useful.
Right, when can we consider REQUEST to be fairly safe? I.e. I know that it cab be manuoulated by any kind of script during the lifetime of a request, and aslo be populated from the URL. I consider manipulation from scripts acceptable behaviour, from the URL not.
Well, there are two answers. First, this is what sessions are really designed for. I am not a big fan of sessions, because they lead to code that is harder to debug, and because the stateless nature of HTTP implies the necessity for implicit timeouts. Sessions do, however, solve this problem, and also can lead to substantial bandwidth reduction. Second, if you have a set of variables that are being handled in the request, you can take care of security yourself. Concatenate the string representations of the variables, and a site or folder specific secret string. Calculate SHA of this concatenated string. Put the variables in the REQUEST per normal, but add the SHA, as well. When the REQUEST comes back, repeat the calculation, being sure to concatenate the strings and secret in the same order and compare the newly calculated SHA with the SHA in the REQUEST. If they differ, either one of the REQUEST variables or the SHA itself has been tampered with. Reject. Jim Penny
On 24 Oct 2003 at 10:35, Stefan H. Holek wrote:
Why is everybody so obsessed with AUTHENTICATED_USER? This variable is not suitable for anything deserving the name "security". It is NOT SAFE to assume that it will contain anything useful.
Thanks for bringing this up. I've changed my code. I had thought that AUTHENTICATED_USER was "a special attribute of REQUEST". -- Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements
Stefan H. Holek wrote:
Why is everybody so obsessed with AUTHENTICATED_USER? This variable is not suitable for anything deserving the name "security". It is NOT SAFE to assume that it will contain anything useful.
Good job core products like RAM Cache Manager use AUTHENTICATED_USER by default then ;) -- Andy McKay ClearWind Consulting http://www.clearwind.ca
participants (6)
-
Andy McKay -
Brad Clements -
Dario Lopez-Kästen -
Jens Vagelpohl -
Jim Penny -
Stefan H. Holek