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