[Zope-Coders] please review LocalRolesRevamp
Shane Hathaway
shane@zope.com
Tue, 09 Oct 2001 14:18:07 -0400
Martijn Faassen wrote:
> Hi there,
>
> I'm not entirely sure if I should be posting this to zope-coders
> or zope-dev; I'd like to avoid lots of crossposts to both lists
> however, so I'm trying this list first.
>
> I've just added a proposal to the fishbowl to improve Zope's
> local roles system. This because I needed computed local roles,
> and I'd like the local roles UI to become more scalable over
> large amounts of users as well.
>
> While the LocalRolesRevamp proposal is still officially in
> EditorialReviewState and not in TechnicalReviewState, but
> I'm just going for technical review anyway. If there's something
> wrong I'll just assume the editor will punish me, or you all will
> yell at me. :)
>
> Anyway, here's the link:
>
> http://dev.zope.org/Wikis/DevSite/Proposals/LocalRolesRevamp
I have a different viewpoint on this that I hope you might consider.
One of the nice features of CMF is that it filters search results based
on what you're allowed to view. It does this by cataloging the list of
roles that are allowed to access the object. Then when you perform a
search it injects a filter into the query that limits what you see based
on your roles.
Simplifying for a moment, say the cataloged field is called
"allowedRoles", you have an object "A", and the roles allowed to access
"A" are ["Manager", "Reviewer"]. When user "R", who has the roles
"Reviewer" and "Authenticated", performs a search, the catalog will add
to the query a filter that matches any of the roles ["Reviewer",
"Authenticated"]. Object "A" matches, so if the other criteria match as
well, it will be returned.
This gets messy when you consider local roles. Today, the CMF catalog
has an "allowedRolesAndUsers" field. It contains not only the global
roles that are allowed to access the object, but also the IDs of users
who are allowed to access it based on their local roles (prefixed by
"user:"). When a user performs a search, the filter that is added to
the query contains, in addition to the list of the user's roles, the ID
of the user, prefixed by "user:".
If you think about it, this strategy works, but has a couple of lurking
problems. They might be major problems for some people.
- You have to be able to precompute the entire list of users who can
access an object. That might not be possible in some environments. (LDAP?)
- If you use local roles to set up areas for workgroups, every object
stored in the workgroup folder is going to have to be cataloged with the
name of every user who can access it. That could be a scalability issue
if there are a lot of people in the workgroup and they manage a lot of
objects.
Another strategy for the CMF catalog would be to use a "qualifiedRoles"
field in the catalog instead of "allowedRolesAndUsers". Roles would be
prefixed with the physical path of the role. So if object "A" is
accessible to the global roles "Reviewer" and "Manager" as well as the
local role "WorkgroupMember" defined in "/workgroups/hr", object "A"
might be cataloged with qualifiedRoles set to
["/workgroups/hr:WorkgroupMember", "/:Reviewer", "/:Manager"].
We could do this if it weren't for one little detail: when a user
searches for content, we would have to precompute a list of all the
local roles the user has throughout the tree in order to populate the
"qualifiedRoles" query. That would eliminate the usefulness of the
catalog query altogether!
So how can we deal with this? Well, what if local roles were stored on
the user object instead of in the object hierarchy? To populate the
qualifiedRoles query, we would ask the user object for the complete list
of qualified roles the user has.
This would have a couple of nice bonuses. Since all roles would be
managed by the user folder, people would be able to manage all user
roles in one place. An administrator would be able to look at *one*
screen to see what a user can access.
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".
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. Another option is to
populate the qualifiedRoles field with all permutations of object
ancestor paths and roles. Object "A" might be indexed with 9
qualifiedRoles. This isn't *too* bad since the number of qualifiedRoles
probably won't reach triple digits. (I can explain that better if you
like, but the special catalog index is probably a better option.)
So, in summary...
I would like to move all local role storage and management to the user
folders. It would make it easier to administrate a system and would
make CMF more scalable.
Shane