-----BEGIN PGP SIGNED MESSAGE-----
cristopher pierson ewing wrote:
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
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
be working so I tend to assume that it may be a
configuration/installation/human error. If you'd like to take a
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
but it is possible we missed something.
The main problem that we seem to be having seems related to the
of the installation - if the plugin is installed at the zope root
acl_users folder, only users listed in that folder with the
will have their permission reflected on all plone sites
the plugin is installed under a plone site's acl_users folder,
with the manager role in that site have the proper permissions,
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)
in a list of Undo options instead of the expected Plugin Types.
The plugin likely needs to check with the "parent" user folder, if
for role assignments, as well as looking in its own map. Likewise
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
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
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
As far as I've been able to tell, the problem seems to be that the
acl_users that gets checked with is the one appropriate to the
the page request made. So, if a page from the zope ZMI is
acl_users in the root zope folder is used for all plugins. If the
requested comes from the plone site, then the plone acl_users is
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
from there attempts to access a plone site page, the role he is
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,
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:
user = acl.getUserById(user.getId())
if user is None:
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
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
granted roles solely on the basis of group memberships. That
to me, it certainly cleans up the picture when trying to figure
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
We haven't been nesting user folders. The problem seems to arise
a default zope installation creates an acl_users 'folder' (really
object), and a default plone installation creates a second one at
of the plone site.
Plone creates both, actually, replacing the "traditional" one in the
The problem seems to be that the PAS object that
exists in the context of the page request made is the only one
information about the roles/credentials of the user making the
and so we are running into trouble.
Is it possible to just delete the acl_users PAS object from the
the plone site? Is it advisable to do so? If we do that, will the
request for plugins to handle authorization and authentication
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
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v220.127.116.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----