[Zope-dev] REQUEST.AUTHENTICATED_USER question

[Leonardo Rochael Almeida]

Hi vio,

Pardon our insistence in helping you out, but you asked to be told if
something in your description smelt rotten and, besides the fact that
yes, you are reinventing the wheel (and reinventing it square, by the
way :-), there isn't a single thing in the scenario you described below
that isn't possible with plain vanilla Zope (ok, plain vanilla Zope is
an oxymoron. There is nothing 'plain' about an out-of-the-box Zope, but
I digress :-), you don't even need CoreSessionTracking as far as I
understand it!

What part of your description below you think you can't do in Zope? If
you mean 'to change the user identity transparently throughout a certain
sequence of clicks', you probably don't want it for it's own sake. If I
read you correctly, you want it so that the user, while holding the new
identity, has permissions it wouldn't have before (and won't have after)
holding the new identity. In this case, you needn't look any further
than 'Proxy Roles'. Proxy roles work sort-of like setuid in unix, in
which you grant different permissions to a user that can view/run a
ceirtain object/file.

When you give a method one or more proxy roles, the user that can
view/call it assumes these roles instead of his own. That means he has
the permissions these proxy roles have, instead of the permissions his
own roles would give him (which means proxy-roles can enhance as well as
reduce permissions). This means proxy roles only work for that method
that is being viewed/called (and other methods called from it as well),
but you can give proxy roles to as many methods as you want, and you can
call a proxy-roled (is that a word? :-) method from other methods and
all the actions that are taken by this proxy-roled method act as if the
user viewing it had the new set of roles.

I'm not sure if that's what you want to achieve, but if it isn't, then
pray tell us what you really wish to accomplish in the end, not just the
things you think you need to do in order to achieve it. I bet there is a
very simple and Zopish way of doing what you want. Maybe you are just
looking at the problem under the wrong light.

Regards, Leo

On Thu, 2002-01-24 at 00:52, vio wrote:
> [...]
> Imagine the following simple scenario, which makes heavy use of 
> 'CoreSessionTracking', by the way:
> 
> 1. In my 'standard_html_header' I put a dtml routine who checks for a 
> specific session variable, let's call it 'user_id'. If it isn't there, or
> there is no session running, it redirects user to my custom 'loginForm'.
> 	<dtml-if "sessionData.get('user_id')">
> 		get the beef
> 	<dtml-else>
> 		redirect to loginForm
> 
> 2. The manage_login() who processes the 'loginForm' data, validates user 
> credentials against some internal list. Actually, for now I'm using a
> standard Users_folder object, but I am tempted to swich to something even
> simpler, like a dictionary or a list. I hope you follow me up to now.
> 
> In that list, each user_id has also associated with it a list of roles. 
> So here we have a central list of 'authorised' users (or a UsersFolder):
> 	clean_users.append([user_id, password, list_of_roles])
> 	or
> 	Users_folder._addUser(name,password,confirm,roles,domains)
> 
> Session-storing the credentials: manage_login() stores this related data
> as session variables:
> 	sessionData.set('user_id',user_id)
> 	sessionData.set('user_roles', list_of_roles)
> 
> 3. Make all user-visible objects in my product 'Public', knowing that 
> they are not 'really' public: any user without a 'user_id' session variable 
> will get redirected to my custom login page 'no matter what'. But Zope's
> own security machinery is out of the loop on this one (simply by-passed).
> 
> 4. The little routine in 'standard_html_header' will take care of all dtml.
> But I will need to call a similar validating method (or specialized instance)
> before running any 'executable' code: 
> by 'executable' I mean code who Creates, Destroys, Modifies restricted objects, 
> or modifies my custom security settings. This code simply compares content of
> 'user_roles' session variable with 'my_object_permissions' object attribute
> (which can be acquired).
> 
> Only if there's a match, the 'executable' python code is allowed to run. 
> An alternative here would have been to protect all objects with a 
> Zope permission (instead of declaring everything public), 
> then switch to a user with that permission for the duration of this 
> transaction with:
> SecurityManagement.newSecurityManager(None, UserWithPermission)
> 
> This is what I ment with "a few well placed calls to the Zope machinery".
> Of course I know I'm not talking to the browser, which is but a dumb client
> with cookies (and no milk). So it's not the browser who tells Zope "I'm
> doctor Zoidberg", but my own code (which acts like a proxy).
> 
> In my view, this scenario implements Zope's security core 'principles' of 
> 'Roles' matching 'Permissions', but using CoreSessionTracking. Writing this
> isn't as complicated as it sounds, only cumbersome to paste code into 
> existing python classes, and edit many dtml pages to add a 'myPermissions' 
> input field to all objects (or at least to the top objects in my hierarchy, 
> and let those custom permissions get acquired from lower down). 
> A full evening's work, for sure. (I think all hackers are optimists by nature)
> 
> My alternative being to study and understand an existing cookie-based
> user-folder product, and make it play nice with my own code. Having tried the
> latter for the last week without satisfactory results (again, only my fault if
> I don't understand totally how things work), I must admit that giving a shot 
> at the former scenario sounds quite tempting. Let's see ...
> 
> But many thanks for all your help and suggestion, which has been very 
> appreciated and useful. If you smell something rotten in my stuff here, 
> please do let me know (besides the fact that I am trying to re-invent 
> the wheel, of course).
> [...]