Hello, while trying to implement a Zope product encountered the following problem: I think I understand the concepts of both users and roles, roles being a set of permissions. In this connection groups (as in Unix) are implemented just by putting the Zope user folders in the right place. When I want to have a more centralized user administration I'd need something like a group attribute for it, so I could give certain roles (in principle I'd just need an editor role) dependent on the user belonging to a certain group. AFAIK none of the products USerDB, GUF oder etcUserFolder provides hooks for this. Where is a good place to start with an implementation and what implications would it have with the Zope security model? thanks for any hints oliver
On Wed, 15 Dec 1999, Oliver Frommel wrote:
while trying to implement a Zope product encountered the following problem: I think I understand the concepts of both users and roles, roles being a set of permissions. In this connection groups (as in Unix) are implemented just by putting the Zope user folders in the right place. When I want to have a more centralized user administration I'd need something like a group attribute for it, so I could give certain roles (in principle I'd just need an editor role) dependent on the user belonging to a certain group. AFAIK none of the products USerDB, GUF oder etcUserFolder provides hooks for this.
A role *is* a group. You grant arbitrary priviledges to a role, and all users with that role (members of that group) will also get those privs. -- ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen
.. an editor role) dependent on the user belonging to a certain group. AFAIK none of the products USerDB, GUF oder etcUserFolder provides hooks for this.
A role *is* a group. You grant arbitrary priviledges to a role, and all users with that role (members of that group) will also get those privs.
well, in principle it isn't I think. However you sure can use roles for emulating some kind of group paradigm. Having a group e.g. for certain folders would not need more than one role for all of them. If I try what you suggest, what's a good way to create a new role when I create a new subfolder? e.g. I have a DTML method for creating new departments' folders, therefor I need to create a new group for each of those with the same set of permissions .. thanks Oliver
On Fri, 17 Dec 1999, Oliver Frommel wrote:
an editor role) dependent on the user belonging to a certain group. AFAIK none of the products USerDB, GUF oder etcUserFolder provides hooks for this.
A role *is* a group. You grant arbitrary priviledges to a role, and all users with that role (members of that group) will also get those privs.
well, in principle it isn't I think. However you sure can use roles for emulating some kind of group paradigm. Having a group e.g. for certain folders would not need more than one role for all of them.
If you define the role in a higher folder, it flows down. If you define your roles in the Zope root folder, then they function exactly like Unix or Netware groups. They would also function exactly like NT groups if role membership could be nested. I define all my users using one acl_users folder. All users have the 'authenticated user' role. They are members of this role throughout my entire site, and I only added the role once to the top of my tree.
If I try what you suggest, what's a good way to create a new role when I create a new subfolder? e.g. I have a DTML method for creating new departments' folders, therefor I need to create a new group for each of those with the same set of permissions ..
If you want to define new roles, use manage_defined_roles defined in the RoleManager base class (lib/python/AccessControl/Role.py). You can call this method on either the folder you have just created, or one of its PARENT folders depending on where you want this role to be visible. If you don't have many roles, you can just define them all in your root container (but if you have larger numbers of roles, your management screens get cluttered, so you define them only in the trees you need them). -- ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen
participants (2)
-
Oliver Frommel -
Stuart 'Zen' Bishop