[Zope-PAS] Re: Failure authorizing with PlonePAS and pubcookie
Michael Gilbert
mdgilb at u.washington.edu
Thu Mar 1 12:58:56 EST 2007
If anyone would like to look at the Role Manager code referenced below,
you can find it at http://staff.washington.edu/mdgilb, along with the
PubcookiePAS plugin mentioned before.
-michael
Michael Gilbert wrote:
> Here's our first stab at creating a custom role manager, working
> almost entirely as it should. It currently behaves quite similarly to
> the regular RoleManager, except that if no roles are found it will
> attempt to get them from the root. The problem we're running into,
> I'm guessing, comes from the fact that since the user 'mdgilb' in the
> context of the /plone site is not the same as the root level 'mdgilb'
> I need to actually load the second by doing something like
>
> root_user = self.getPhysicalRoot().acl_users.getUser(principal.getId())
>
> Once I get the root user, I can get the roles in the proper context by
> just doing
>
> roles = list( root_user.getRoles() )
>
> This portion of the code actually seems to work, since the proper
> roles are returned. The problem comes when after the roles are
> returned a loop seems to happen in getRolesForPrincipal. Every time
> 'user = new_self.getPhysicalRoot().acl_users.getUser(Id)' is called
> getRolesForPrincipal goes back to the beginning, so I'm thinking the
> initial call to getUser is causing some value to be misread later on,
> which causes the loop. Another point to note is that when the method
> is first called, my username (mdgilb) is properly listed in the
> principal value. In successive calls another user (peggyros) is
> listed, which is just not right.
>
> If anyone could offer any insight into this issue it would be
> greatly appreciated.
>
> Thanks,
> -michael
>
> cristopher pierson ewing wrote:
>
>> Tres,
>>
>> Again, thanks for the replies on this. Your input has been
>> invaluable in working out what's going on here.
>>
>> We had another little debugging session the other day, and have come
>> to a few conclusions about what is needed here and what we should
>> do. I wanted to send a quick note to you with our plans, just in
>> case anything we are thinking is so clearly stupid and dangerous that
>> you want to jump up and say 'STOP!'. ;)
>>
>> We've definitely narrowed the problem down to the role manager
>> plugin. The issue is that when a user is set up in the zope acl_users
>> PAS object, and given the role of manager, that user cannot access
>> the ZMI or pages of a plone site installed in his/her zope instance
>> as a manager. The reason for this is definitely that the acl_users
>> PAS object in the Plone site has a 'role manager' plugin available
>> that is cansulted and it only returns the roles for the user that are
>> defined in the context of that PAS object. Since the 'Zope Manager'
>> we defined above is not listed in the Plone PAS object, no roles are
>> returned, and the user is given the base role of 'Authenticated User'.
>>
>> We've decided that this problem is really not one that is directly
>> related to the PubcookiePAS plugin, but rather external to it. So
>> we've decided to create a new, single plugin that provides the IRoles
>> interface, but checks upward to parent folders for valid PAS objects
>> in which to look for roles. We figure that if we make such a plugin,
>> then adding it to the active list of role manager plugins in any
>> plone site installed in our Zope instance will allow them to find
>> zope-level manager roles for zope-level managers, and apply those
>> roles to pages within the plone site.
>>
>> The only reason we need to do this at all is because the folks I'm
>> working with have a setup where they are running several plone sites
>> from a single zope instance, and they want to be able to set up
>> 'global' managers from zope who will have permissions to manage all
>> the plone sites. Since I don't need to do this, and many others may
>> not. It seems wise to put this plugin in a product of its own,
>> rather than including it in my PubcookiePAS multi-plugin product.
>>
>> Any alarm bells ringing here?
>>
>> Thanks again for your help so far. You've been great.
>>
>> Cris
>>
>> ********************************
>> Cris Ewing
>> CME and Telehealth Web Services
>> Department of Radiology Web Services
>> University of Washington
>> School of Medicine
>> Work Phone: (206) 685-9116
>> Home Phone: (206) 365-3413
>> E-mail: cewing at u.washington.edu
>> *******************************
>>
>>
>> On Thu, 15 Feb 2007, Tres Seaver wrote:
>>
>>> -----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 tseaver at palladion.com
>>> 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-----
>>>
>
> _______________________________________________
> Zope-PAS mailing list
> Zope-PAS at zope.org
> http://mail.zope.org/mailman/listinfo/zope-pas
More information about the Zope-PAS
mailing list