-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
cristopher pierson ewing wrote:
Tres,
I'm the poor lug who wrote the plugins in queestion. Thanks again for
helping out with this. I've got some questions and some ideas
folded in
with your response below.
On Tue, 13 Feb 2007, Tres Seaver wrote:
Thanks for responding.
The multi-plugin was written by Cris (cc'd above) here at UW. The
plugin isn't incredibly invasive, and in fact at one point it
seemed to
be working so I tend to assume that it may be a
configuration/installation/human error. If you'd like to take a
look at
it, I've copied a tarball and the extracted contents out to
http://staff.washington.edu/mdgilb/ for perusal. We've done a fair
amount of debugging to the plugin and haven't found a blaring
error yet,
but it is possible we missed something.
The main problem that we seem to be having seems related to the
context
of the installation - if the plugin is installed at the zope root
acl_users folder, only users listed in that folder with the
manager role
will have their permission reflected on all plone sites
underneath. If
the plugin is installed under a plone site's acl_users folder,
users
with the manager role in that site have the proper permissions,
but root
level managers (ie zope admins) will have a limited set of
rights - once
the plugin is enabled for the final plugin type, trying to view all
available plugin types again (/<SiteName>/acl_users/plugins)
will result
in a list of Undo options instead of the expected Plugin Types.
The plugin likely needs to check with the "parent" user folder, if
any,
for role assignments, as well as looking in its own map. Likewise
for
group membership, if your roles are assigned to groups, rather than
directly to users.
The plugins I wrote don't have any component for checking group
membership
or roles (as far as I know). There's only four plugins defined in the
folder, a Challenge plugin, an authenticateCredentials plugin, an
extractCredentials plugin, and a resetCredentials plugin. As far as I
have been able to tell, group membership seems to be handled by the
'source_groups' plugin in the plone acl_users and by 'groups' in
the zope
acl_users. The same goes for role acquisition. There appears to be a
role manager for the plone acl_users and another for the zope
acl_users.
As far as I've been able to tell, the problem seems to be that the
only
acl_users that gets checked with is the one appropriate to the
context of
the page request made. So, if a page from the zope ZMI is
requested, the
acl_users in the root zope folder is used for all plugins. If the
page
requested comes from the plone site, then the plone acl_users is
selected,
and the plugins come from there. The problem seems to arise in
that if a
principal defined in the zope acl_users and given the role of
'manager'
from there attempts to access a plone site page, the role he is
granted by
the zope acl_users is never found, because the role manager consulted
comes from the plone acl_users, and the principal doesn't exist there.
You've got your finger on the crux, here: the user identified by
pubcookie is being "recognized" by the child PAS (becuase of the
cookie), but is *not the same user* as the one in the root: she just
happens to have the same userid as the one defined in the root. This
would be the same problem if you created "traditional" user foldere and
defined users with the same ID in both parent and child: any role
assignments made to the parent would be "shadowed" by the presence of
the doppelganger in the child.
As a hack, I might try adding another method,
'getRolesForPrincipal', on
your plugin, and register it as an IRoles plugin. In that method, you
will need to check the global roles of the user with that ID in the
*parent* user folder, and add them to any assigned there.
In fact, you might be able to accomplish this via a
'DelegatingMultiPlugin' (or at least steal the code from there). Here
is what its 'getRolesForPrincipal' looks like::
def getRolesForPrincipal(self, user, request=None):
""" Fullfill RolesPlugin requirements """
acl = self._getUserFolder()
if acl is None:
return ()
user = acl.getUserById(user.getId())
if user is None:
return ()
return tuple(user.getRoles())
In your case, the only hard part would be that first call, to
'_getUserFolder': you would need to replace it with something which
looked at the "grandparent" of the plugin to find the containing user
folder:'(aq_parent(aq_parent(aq_inner(self)))'.
In general, I would break apart the idea of group membership, which is
typically done globally (within the entire scope of the user folder),
from role assignment. Mostly, I avoid doing "global" role assignment,
preferrning instead to grant roles to the groups as "local roles".
So, if I read this right, you are suggesting that a principal
should be
granted roles solely on the basis of group memberships. That
makes sense
to me, it certainly cleans up the picture when trying to figure
out which
roles to apply.
I'm also pretty convinced that you don't really want or need more than
one user folder, in general at the root of the Zope database: the
complexity caused by nesting user folders outweighs any benefit I've
ever identified.
We haven't been nesting user folders. The problem seems to arise
in that
a default zope installation creates an acl_users 'folder' (really
a PAS
object), and a default plone installation creates a second one at
the root
of the plone site.
Plone creates both, actually, replacing the "traditional" one in the
root.
The problem seems to be that the PAS object that
exists in the context of the page request made is the only one
asked for
information about the roles/credentials of the user making the
request,
and so we are running into trouble.
Is it possible to just delete the acl_users PAS object from the
root of
the plone site? Is it advisable to do so? If we do that, will the
request for plugins to handle authorization and authentication
bubble up
to the zope instance of acl_users? Perhaps this would solve all our
problems, but it's a little scary to do.
It is certainly possible: you would need to ensure that you recreate
any state in the child folder (properties, etc.).
Thanks again for your help
You're welcome.
,
Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF1GXX+gerLs4ltQ4RAuBVAJ9Xj8OPT7Y4Q2B/ZVziD4Wr8ENqWgCfUzNV
adwPxPSEarKQj0+5p1PFyvo=
=5b6u
-----END PGP SIGNATURE-----