Skip to content.

plone.org

Sections
Personal tools
You are here: Home » Development » Plone Improvement Proposals
Log in
Development
You can submit bug reports and feature requests to the Plone Collector
We currently host development of Plone at SourceForge
There is also a development Wiki available for the Plone Developers.
Help regarding Plone development and deployment is available in the news groups and mailing lists.
zopelabs
 
Views

PLIP16

last edited 1 month ago by DannyB
  • Description - Proposal to enhance the way Zope and also Plone deals with local-roles.
  • PLIP - 16
  • Proposer - Danny Bloemendaal (ender-)
  • Seconder - Who volunteers?
  • Status - Awaiting feedback

Contents

  1. Definitions
  2. Motivation
  3. Assumptions
  4. Proposal
  5. Implementation
  6. Deliverables
  7. Risks
  8. Time line

Definitions

Local-roles
Roles given to a user or a group in a specific folder or object.
Local-roles acquisition
The way local-roles are inherited or acquired from parent folderish objects.

Motivation

The current local-roles implementation in Zope makes it impossible to reduce the rights given to users when you go deeper in folder hierarchy since roles, once given to a user, cannot be taken away from a user. Therefore it is impossible to have a really flexible and moreover easy-to-use way of dealing with security. An ideal situation would be that you are able to provide access to your site-root to everybody by giving the whole group the proper role and when you go deeper in the structure, you start restricting access by redefining the local-roles in that context. Right now, you can't really do that without using tricks with workflows and even then it is very limited and very confusing and counter-intuitive.

Even when PLIP7 is fully functional, you still can't restrict access to certain folders inside GroupFolders? for users that have access to the GroupFolder? itself. You can think: why would you do that? Well, there are numerous situations where you want this. Of course you can define a workflow-state that give permissions to certain roles but once you have given a user this role and you want to further restrict his access to subfolders, the only thing you can do is to create a new role and a new workflow-state, a new role that the user doesn't have already. But this only postpones the problem to a folder level deeper. This PLIP describes the solution and would make live a lot easier.

Assumptions

For this PLIP I assume that we use Group User Folders (GRUF) as a starting point but it's not necessary.

Proposal

The proposol for this PLIP is to enhance the way GRUF checks for local-roles in such a way that before it traverses up the folder hierarchy, it checks if the current folder is set to acquire local-roles from parents or not. This check is done for every parent it finds on its way up the tree.

Implementation

Implementing looks quite simpel and I have done some tests that have been very promising. At first, in the Sharing page in Plone a check-box is added where the user with proper permissions can check if he wants to acquire the local-roles from parent folders or not. The selection is then stored as a property on the folder/object.

The next step would be to alter the function in GRUF that returns the local-roles in a given context. As far as I can see this happens in GRUFUser?.py in the function getRolesInContext. Inside that function is a simple loop that does the traversal. In this loop a check needs to be done on the current object to see if it has set the property for acquisition or not. If set to false, the loop will stop.

As I said, I did some tests and it seemed to work. I did encounter a problem that I couldn't fix and it seemed at that time only remotely related to this but I'm not sure exactly what this problem was back then (sorry). I expect that when enough skilled people take a look at this, this can be fixed. And like I said, the idea is simple but the implications are huge and could make our lives sooo much easier.

Deliverables

A small modification to GRUF and perhaps other functions when GRUF is not used. Also a slightly altered template for the sharing settings in Plone.

Risk Factors

As far as I can see, the risks are minimal although hardly anybody dares to do something with Zope security. So let's figure out if this can be done. The rewards are great.

Time line

Implementing can be done in a few hours since it only requires a few lines of code unless....unless I have overseen implications here.


comments:

This has actually already been done --limi, Fri, 09 Jan 2004 17:01:25 -0600 reply
http://zope.org/Members/regebro/LRBlacklist - an old, (now) non-functional implementation of the same. Might be useful to look at for other implications that might be overlooked.

This has actually already been done --DannyB?, Sat, 10 Jan 2004 02:07:47 -0600 reply
I did see this yes and it is old so I have no idea what the status is. Let's see if the author still exist ;-)

 

Powered by Plone

This site conforms to the following standards: