[Zope] acquisition, traversal, acl_users and security

Dylan Reinhardt zope@dylanreinhardt.com
Thu, 27 Feb 2003 12:11:22 -0800


Let's give this another try...

At 10:29 AM 2/27/2003, Tim Hicks wrote:
> > This is more an HTTP issue than a Zope issue.
>
>I'm not convinced about that.

Under HTTP 1.1, IIRC, if a browser authenticates by a request to

http://server/a/b/c

then it should, by default, assume the same credentials apply to

http://server/a/b/c/d

but not to

http://server/a/b

which must be authenticated separately.


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

If I read you correctly, you deleted the user that had the local role, 
leaving the one without a local role.  Creating two user objects at 
different levels does not provide one account that can apply at two 
levels... it provides two different users with different privileges at 
different places who just happen to have the same name.  Which one you're 
working with will be determined by what you requested when you authenticated.


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

OK... I think I'm following you now.

Say your hierarchy looks something like this;

sites/
     control/
     vhost1/
         acl_users/
         index_html
         some_folder/
     vhost2/
         acl_users/
         index_html

You want to be able to call URLs like:

http://vhost1/control
http://vhost1/some_folder/control
http://vhost2/control

But you want the privileges that control runs under to be determined by 
where in the folder hierarchy the user is working.  Right so far?

If so, you're in luck.  Virtually no difficult work will be required.  The 
most important thing will be to create *one* user object per human user and 
to assure that each user object is put as high in the hierarchy as it is 
meant to apply.  Restrict access to deeper folders by cranking up the roles 
required, not by creating additional acl_users.

Now, when a user calls something like:

http://vhost1/some_folder/control

it is OK to leave control totally open to anonymous users.   This way, the 
user's level of access to the contents of some_folder are still what 
determines the need for authentication.

Thus, if control/index_html makes use of some restricted attribute of its 
acquisition parent, the parent's security will kick in if index_html's 
doesn't.  Since we leave index_html totally open, we'll get the parent's 
security every time.  Be sure not to give the contents of control any proxy 
roles in this scenario... that could be a very bad thing.

Is that a bit closer to what you're looking for?

This is top-of-the-head, untested, broad-strokes stuff, but hopefully useful.

Dylan






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