[Zope] acquisition, traversal, acl_users and security

[Tim Hicks]

Hi Dylan,

thanks for your super-fast response :)...

Dylan Reinhardt said:
> 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.

I'm not convinced about that.  I didn't add last time that I did another
test.  I defined a user 'test' in site_root_folder/acl_users (without a
role), then assigned a local role for the 'test' user in folder1.  I also
removed folder1/acl_users.  This meant that authentication was being done
by site_root_folder/acl_users, but I was still getting Unauthorized.

> 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.

Why is that?  I don't see how that helps me.  Anyway, I don't want these
edit screens to dictate site structures etc.  I really just want a drop-in
replacement for /manage (which works everywhere).

> 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.

Hmm, I don't want their priveleges to apply two levels up, I want the
'control' folder to recognise that it is (by acquisition) now in 'folder1'
and then allow the 'Manager' defined in folder1/acl_users to 'View'
folder1/control/index_html (which is a listing of folder1 contents).

> The  easiest way to hack this is by giving a proxy role to the method in
>  question.

Do you mean giving control/index_html a proxy role of manager?  I don't
think that would work but I don't think that is what you mean.

>  Another fairly easy trick is to use a method at their level
>  that uses unrestrictedTraverse() to circumvent security policies on
> their  behalf.

Have you got an example of what you mean here?

[... roles stuff ...]

For the current project I'm working on, the roles are pre-defined and not
changeable by me.  Even so, the notion of not wanting the management
screens to dictate site setup (as far as possible) still stands.

cheers,

tim