Ticket #4055 (closed Bug: fixed)

Opened 9 years ago

Last modified 5 years ago

Insuff priv when allowing access to object in restricted folder

Reported by: DannyB Owned by:
Priority: critical Milestone: 2.1
Component: Templates/CSS Version:
Keywords: Cc:

Description (last modified by wichert) (diff)

With plip16 in place it is now possible to restrict access to sections in the portal. However, there is a problem when I want to allow access to an object that sits in a folder that is restricted:

Steps to reproduce:

  1. Add a new user and don't give him a role.
  2. As admin, create a folder in portal root
  3. Go to that folder's sharing tab and uncheck 'inherit roles'
  4. In that folder, add a Document.
  5. Publish that document
  6. Go to the sharing tab and give the new user Member role there (or any role that should give him view permissions, Manager will do too).
  7. Log in as the new user and go to the new Document. He must be able to view it but plone throws an insuffpriv error.

With plip16 in place, these kind of situations must degrade gracefully. It must be possible to do these things. That was the whole point of this plip. It affects several things. Like the breadcrumbs. It should show in the path that along the way to the object being viewed, there are restricted folders in the path. Also, the batch view action checks for permission on the containing folder which the user has no access to. Etc.

Change History

comment:1 Changed 9 years ago by alecm

Cannot reproduce with default workflow/security settings. Also can't reproduce with various more restrictive permissions/workflow attempts. I can't really see how this could be true as unchecking the acquire local roles box shouldn't have any effect if no local roles are assigned (only a global Member/Authenticated role exists in this case and that won't and shouldn't be blocked). In the default workflow if the document is published it's visible even to users with no roles (Anonymous).

comment:2 Changed 9 years ago by DannyB

Ok, I made some new steps. The following are to modify the workflows:

plone_workflow/states/visibile/permissions:

  • uncheck all acquire boxes
  • uncheck all anonymous boxes
  • uncheck all authenticated boxes
  • check all manager boxes
  • uncheck all member boxes
  • check all owner boxes

plone_workflow/states/published/permissions:

  • uncheck all acquire boxes
  • uncheck all anonymous boxes
  • uncheck all authenticated boxes
  • check all manager boxes
  • check all member boxes
  • check all owner boxes

These settings are made to make the visible state restricted for manager/owner only (just as an example) and published visible for members too.

Do the same for folder_workflow (visible and published).

Then make sure the added user doesn't have any role initially so in gruf, uncheck his member role. The idea is that users only get roles assigned using local roles which is exactly what plip16 is aiming at.

Now, create a folder and make sure it is in the visible state and turn of local-role acquisition. Then create a Page in that folder and give that Page the published state. Also, give the user a local role on that page as Member. Log in as that user. You can use livesearch to see that he has access to the Page. Go to that Page and you will get the insuff privs.

This usecase is typical in intranets or when you want to restrict access to folders but grant access to subobjects. Plone must make this possible or degrade gracefully. Of course, the folder is not accessible and going there should give the insuff priv. But going to the subobject must be possible. Problem is the navtree which shows the parents and the breadcrumbs. From a UI perspective, the navtree must show something like <..> for folders the user has no access to. The same for the breadcrumbs.

comment:3 Changed 9 years ago by alecm

  • Status changed from new to closed
  • Resolution set to fixed

Fixed in SVN. However you will need to grant 'Access contents information' on folders to Anonymous if you want anything immediately below the protected folder to be accessible to Anonymous, or to Authenticated if you want to allow logged in users without roles on the parent to access contained content. In general, it is probably best to leave Acquire checked on this permission for folders unless you are fully aware of the consequences.

comment:4 Changed 7 years ago by wichert

  • Description modified (diff)

comment:5 Changed 5 years ago by hannosch

  • Component changed from Visual and templates to Templates/CSS
Note: See TracTickets for help on using tickets.