[Zope] acquisition, traversal, acl_users and security

[Tim Hicks]

Hi again,

Dylan Reinhardt said:

> Let's give this another try...

[... HTTP 1.1 stuff ...]

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

That's absolutely what I want :).

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

Yeah, this solution came to me this morning as well, although I haven't
tried it yet.  The only downside I can see is that all users would be able
to see the management screens.  This may potentially reveal more
information than is desirable (depending on what the management screens
show of course).

Seeing as I have a single page template macro controlling layout of all
pages within 'control', perhaps I could put a little code at the top there
to check permissions and block anonymous users.  I'll have to experiment.

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

Indeed.

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

Yeah, that's great.  I really appreciate your input.

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

Cheers,

tim