At 09:57 AM 2/27/2003, Tim Hicks wrote:
In the 'control' security tab, I've left everything on 'Acquire Permissions' except for 'View', which I've limited to 'Manager' only. This works well when the user logging in is defined in an acl_users that is a sibling of 'control', but does not work when the acl_users is defined further down the tree and 'control' is being acquired.
This is more an HTTP issue than a Zope issue. A best practice here is to design your Folder hierarchy such that the most widely-available, least-restricted stuff is closer to the root and the more specialized, restricted stuff is off on the branches. But let's say you've got what you've got. Your user is authenticated three levels in and you want their privileges to apply two levels up. The easiest way to hack this is by giving a proxy role to the method in question. Another fairly easy trick is to use a method at their level that uses unrestrictedTraverse() to circumvent security policies on their behalf. But it may be just as easy to have one acl_users and work a little harder on creating finer-grained roles. Perhaps some of these roles are mostly entitled only to use methods that are several levels in... but one or two methods at the site root could be made to respond to those roles as well. For a decent-size site of any complexity, I'd recommend putting effort into designing your roles up front. It's going to be a lot easier to figure out who can do what later on if you save proxy roles and magic traversal for the truly exceptional cases. HTH, Dylan