Hi,

I'm playing around with building a cookie-based authentication Zope product, and I've been learning a lot about users, roles, local roles and proxy roles ... So I was wondering if my understanding of the proposed Owner role (given that documentation is very scanty) is correct, incorrect, or simply needs clarification.

The thing is, my setup is working, but who knows what bugs may lie just around the corner, merely because I misunderstand the concepts... (and since I'm dealing with an authentication product, is *_specially_* important).

I'm using the Owner role in the context of allowing a user to change his/her passwords. I suppose I could create another role to fulfill this, so its really not a big deal if I shouldn't be using the Owner role for this purpose:

So this is my setup :

1. For a given Folder for which I am creating my cookie-based UserFolder (named acl_users, of course) I create a role known as a cookieLoggedUser. All users that are created in acl_users have the cookieLoggedUser role automatically added to their roles profile (and cannot be deleted).

2. In this Folder, there are dtml methods to allow you to login/logout etc. (they are working fine and are of no importance to the issue at hand) When users log in, they acquire the role of cookieLoggedUser (along with the other roles defined for their user id, of course).

3. the acl_users permissions are modified to allow the 'Owner' role the privilege to "manage_users". (Is this advisable or is this a big security hole?)

4. I have a DTML method that displays the Change Password form (it submits the page to itself and I use a hidden form variable to check whether it should process the form or not).

5. This method has its permissions set so that only users with the cookieLoggedUser role can 'view' it or 'access contents information'. This means that Anonymous users can't see this page unless they log in first, in which case they acquire the cookieLoggedUser role.

6. The processing DTML code calls the acl_users methods to change the password (and has safeguards against logged-in users from changing anybody else's passwords except their own). Because they access the acl_user's methods which require 'manage_user' privileges, I gave this method a proxy role of 'Owner' so that it can execute these privileged methods.

Some notes:

a. I don't *_have_* to use the Owner role for this purpose. (I could easily create another role expressly just for accessing the acl_users privileged methods and my system would still work) but I do want to understand if the 'Owner' role is meant to be used in this context or not.

b. If you give a user the Owner role, (along with the view management screens, of course), you allow him/her the privilege to 'manage_users'. My understanding is that you normally *_dont_* give this role out to any ordinary user?

If this is incorrect, then my whole theory sinks down the drain... OTOH, if I'm incorrect, then just what the heck is the 'Owner' role for?

c. I've thought about possible security holes and think (given the levels of security HTTP protocols can give, of course) it's fairly secure. It could be made more secure by encrypting the cookie better and providing a secure channel (i.e. SSL).

d. I'd really like to hear the opinions of those in the know, especially about how we should use the 'Owner role' (of course, we can use it for any purpose we want to, but I want to know the *_right_* way to use it, i.e., the way it's meant to be used).

Thanks in advance,

Butch Landingin

Butch, The theory behind the "Owner" role is that: o when a user creates a new object, he/she automatically gets the local role "Owner" for that object. o As a site manager, you can set reasonable permissions for the "Owner" role at the top of your site, which will be acquired when folks work with objects that they have created. This means basically that you can reasonable laws of ownership (what people can do with objects that they have created), without having to visit every object that someone creates *and* without necessarily giving them the ability to modify security settings themselves. For example, lets say that you create a folder called "home" on your site. For the security settings for "home" you say that the "Owner" role can Create Documents Images and Files, Edit Docs Images and Files and Delete objects. Now you can create a new Folder inside of "home" for each user who should have a home area, and give them the local role "Owner" in that Folder. Having done that, your users can each create, edit and delete document in their own folders - but they *can't* go over and mess with their neighbor's Folder, because they only have the "Owner" role locally in their own Folder. The situation you describe above doesn't sound like it needs to use any of this. In your situation, the best (and most secure) approach would be to avoid giving any of your users "manage users" permissions directly. Just give the "Manager" proxy role to your password-changer form and make sure that "Manager" has the manage users permission. This way, it is effectively actually your *form* that has the permission to fiddle with user data, not the users themselves. The form logic itself should be able to ensure that a user can only change his own password. Hope this helps! Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com