[Zope-Coders] please review LocalRolesRevamp

[Shane Hathaway]

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.

> So you propose I implement my own User.allowed() method, not looking at
> __ac_local_roles__ at all (at least not for computed local roles)? I could
> copy & paste allowed() and hack it up, but that seems like such a kludge.
> It would also not improve Zope in any way. It would be hard to
> maintain as well; each time allowed() changes my own user object needs
> to change. My proposal avoids all that; allowed() is only changed
> once to deal with the new local roles interface (a small change) and
> we do any particular computation we like behind that interface.

You could override getRolesInContext(), I think.

> > >>There's a new catch, though.  When you catalog an object you have to be
> > >>able to compute a list that will match all possible qualified roles.
> > >>What if someone has the "WorkgroupMember" local role in the
> > >>"/workgroups" folder?  That should grant them access to object "A".
> > >>
> > >
> > >I think I just described this problem, with the added complication of
> > >dynamically computed local roles. And the trouble is still that
> > >even with the current local roles, who is assigned what roles where
> > >can change, invalidating your catalog. So I ask the philosophical
> > >question whether this is a problem you actually want to solve;
> > >how much dynamism do we need to give up before something can be
> > >cataloged?
> >
> > 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.

> If user A receives a local role Manager in some folder close to the root
> in the tree, the catalog is likely to become wrong for that user when
> he queries it, right? It would return far less objects that it should,
> because when the object was cataloged the user could not access a lot
> of objects that he now can.

That's the way it is today.  What I suggested would fix that.

> 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.  I'd like to see a solution that can meet the
searching goal as well.

> > What currently happens is user names are stored in
> > the catalog, and I proposed taking out all user names and replacing them
> > with object roles.  The catalog would only contain static information.
>
> Right; if I understand you right, the object roles are already in there,
> and the usernames are just a hack to make local roles work.

Right.

> > >>There are two answers to that question that I can see.  One is to create
> > >>a special catalog index for the purpose of role-based filtering.  It
> > >>would take into account the inheritance rules.
> >
> > >Wouldn't work for computed local roles, though, right?
> >
> > 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.

> 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.

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.

> 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. :-)

Shane