[Zope-Coders] please review LocalRolesRevamp

[Martijn Faassen]

Shane Hathaway wrote:
> On Wed, 10 Oct 2001, Martijn Faassen wrote:
> 
> > > Will you provide a search form that filters by access?  You may need it.
> >
> > I don't understand what you mean. Filter what by whose access?
> 
> A lot of Zope sites need to filter the results of a catalog search
> according to the roles available to the user.  I don't know whether that's
> the case for you.

Yes, I think this will eventually be necessary in some way.

[overriding User] 
> You could override getRolesInContext(), I think.

An optimization was introduced in Zope 2.3 (I think) that makes this impossible.
getRolesInContext() is I think not used by the core anymore.

[snip]
> > > You're confusing object roles and user roles.
> >
> > I'm talking about __ac_local_roles__, a dictionary which associates
> > user ids with roles, which is acquired by objects. I don't know if
> > they're user or object roles, but I'd say they're 'local roles'. :)
> 
> Local roles are "non-global user roles".  Object roles vary rarely; user
> roles vary often.  One problem with the __ac_local_roles__ attribute is
> that since it's a persistent attribute, it should vary rarely.  Yet it
> stores something that can vary frequently.  It could be computed, but then
> you can't solve the problem with the catalog.

Right, my approach would be to have it computed, but as you said, then
you run into the cataloging problem. Tradeoffs, tradeoffs. I'm in
favor of computed, but I can see the arguments for being against it.
 
[snip current situation]
> > The catalog cannot be aware this user now has that extra role for those
> > objects, unless you update the catalog for all objects in that folder
> > each time a local role is set for a user in that
> > folder, which seems excessive (and precludes computed local roles).
> >
> > You can fix this by maintaining local roles in the user object itself
> > and using a special catalog index that knows about acquisition of local
> > roles when determining if someone has access, as you propose (right?).
> > As you say later, there could (and should) still be management methods
> > hooking into this associated with the folders itself, otherwise
> > only people with access to the user folder can change local roles
> > settings. I was initially confused about this, as you seemed to
> > imply the UI would be in the user folder at first.
> >
> > Perhaps I'm misunderstanding something.
> 
> You're getting close. :-)
> Computed local roles and catalog searching are
> not at odds unless you choose to just use __ac_local_roles__ for
> computing the local roles.

Yup, agreed. Unfortunately I don't see how to avoid some construct
like that for useful computed local roles.

> I'd like to see a solution that can meet the
> searching goal as well.

Sounds good.

[snip would computed local roles work for this approach?]
> > > It could, actually.  Since the catalog would store object roles only,
> > > which don't change often, you would be in a better position than you are
> > > today to use computed local roles.
> >
> > Except that they need to be computed relative to the objects in
> > the tree.. i.e. to know if I have computed local role X for object
> > Y, I need to ask object Y first for its particular user metadata ->
> > local role mapping (which it'll try to find using acquisition and by
> > going up in the tree). Thus, in order to compute the list of roles I
> > have for particular paths in the site, I would need to access *all*
> > the paths in the site to ask what its particular mapping of
> > user meta data to local roles is.
> 
> Yes, you're understanding. :-)  That's why there needs to be centralized
> management of local roles.  I need a way to quickly ask what global and
> local roles the current user has, so I can feed them to the catalog.

Right, but the computing goal is at odds with this, which is what I'm
trying to describe here. In order to determine whether I have access
to object Y, I need to go to object Y and ask how it wants user attributes to
map to local roles in its context.

> > As far as I can see it you can't compute this without actually asking
> > the objects you're trying to access.
> 
> If you centralize the management of local roles then you don't have to ask
> the objects about roles.

But you'd need to in order to accomplish some use cases. What I'd like to
compute is user attributes to local roles. This computation is place
dependent; in place A in the tree I'd like user attribute 'employee' to
have, say, 'Manager' rights, but in place B I'd like the same user
attribute to only have 'Authenticated' rights. It seems hard to avoid
actually going to the place and asking what their mapping is in this
scenario.

> Another possibility is that local roles could be managed by a different
> object entirely--neither the user nor the object.  You could add
> expressions and scripts to the object to make local role computation
> happen.  You would be able to ask it for all the roles and local roles a
> given user has.  It might even compute all user roles based on some series
> of expressions.
> 
> Come to think of it, that's probably the best solution.  Philip Eby has
> talked of something like this and Evan reminded me of it today.

And those expressions and scripts could then hook into various parts of
the tree.. It would still be less expensive than calculating the local
role for each *object* found by the catalog, which is the simplest to
implement approach towards computed local roles. But how would they
hook into the tree? They should only hook to the relevant places.

What this local role management solution could do is keep a catalog of
all objects in the tree that wants to compute local roles based on
user attribute data (or REQUEST context, etc). Each time you ask a user
object for all its roles (including local roles), the local role 
object goes off and asks all the objects listed what local roles they
would compute for this user.

Per user you'd still have to go off asking dozens if not hundreds of
objects for this information, though, in large sites where this is
used a lot. You could employ some caching here though, and it'd still
be less expensive than filtering cataloged objects each time (which can
easily run into multiple hundreds).  

> > Your solution (storing local roles in the user object instead of
> > on the folder, combined with the fancy cache indexes that know about roles)
> > would maintain the current functionality with regards to local roles,
> > and would allow better caching.
> >
> > What I need however is more than the current functionality allows, and I can
> > see a way to give local roles quite a bit more flexibility by allowing
> > them to be computed. Storing local roles in the user object would make this
> > hard to do, as far as I can see. And I don't quite see how else to
> > reach my goals, which do not seem unreasonable. I could of course give
> > up and store local roles for groups in Zope directly, computing them
> > and caching the results in Zope, only improving the management screens to
> > make the management of these a bit easier..
> 
> Our difference of opinion is, AFAICT, rooted in different perceptions of
> the need to filter catalog results based on access.  Obviously you don't
> have that goal. :-)

Sure, but that's why we're talking, right? I have my goal, you have your
goal, and we're trying to figure out some approach that would make us
both moderately happy. What do you think about the approach I listed above?

I'll try to think up some set of interfaces that would be needed to accomplish
this.

Regards,

Martijn