[Zope-dev] LOTS of roles?

Paul Winkler pw_lists@slinkp.com
Mon, 24 Feb 2003 17:07:30 -0500


On Mon, Feb 24, 2003 at 07:18:21PM -0300, Leonardo Rochael Almeida wrote:
> 
> I don't think a multitude of roles is the way to go. The way your
> problem sounds, you need users being allowed/forbiden to do certain
> tasks depending on which part of the site they are. This is what
> local-roles are for: parameterizing the permissions of a user based on
> the location of the objects inside Zope.

Yes, except that Oliver hit the nail on the head when he said:

"""From that I gather that your "sites" don't map 1:1 to objects into
zope, so that you cannot use local roles for that, right?
E.g, there are methods like doTaskX(location,...), where the permission
to execute that method depend on location, and location is not an object
inside zope.
"""

> However you do mention that you need to manage this centrally,
> especially since this information won't be used by Zope alone (and even
> if it was, you need centralized administration of these local roles,
> something that Zope doesn't give you, unless you consider Zope "central"
> :-), which I think you don't, because you consider LDAP "central". Is
> this correct?).

yes.

> So I think you need dynamically calculated local roles. This can be
> achieved by a user folder that returns a user object that overrides
> ".getRolesInContext(object)" to take the location (or any other
> attribute, such as an acquired "site") of "object" and check it against
> your central authorization source (eg. LDAP).

hmmm... now i'm leaning back this way again.
some quick testing with a large number of roles (10,000 added
via a ZEO debug session) reveals that performance does indeed
suck with that many roles. i could pursue the optimization that 
Dieter suggested but i'm no longer sure that I want to; the "lots of roles"
idea was a lot more attractive when I thought it would be only
a UI issue.  Instead it looks like I'd have to make substantial
changes in lib/python/AccessControl and there's a few more thousand
lines of code in there which I haven't even looked at yet.

> exUserFolder has had modifications to allow construction of
> authentication sources that override user.getRolesInContext, but none of
> its default auth sources use this so far.
> 
> Hope I made some sense :-)

I think so. This stuff makes my head hurt. :)

-- 

Paul Winkler
http://www.slinkp.com