I think the case for a feature enhancement is strong, though. Several other people have made similar requests and I believe Oliver proposed a solution that would allow inherited acl checking without the user needing read access to parent folders. My only concern with this is that since it differs from the way most security systems work an unaware administrator could accidentally open a security hole without realizing it. If this behavior had to be enabled explicitly, I think that would no longer be a problem.
As for a timeline, we're in a feature freeze for 2.1 right now, so depending on the magnitude of the change (I haven't looked at what would be involved) it may have to wait until 2.2.
-James
Gao Jun wrote:
James,
I think the root cause of all these problems is Slide requires a user
to have read privileges on all upstream folders to enable himself to write
in a folder he has write privilege on. I think this is not a reasonable rule
and it brings out quite some problems. So I'd like to know whether you
take this as a defect and have a plan to fix it in the near future?
regards,
Jun
James Mason <[EMAIL PROTECTED]> wrote: Gao Jun wrote:
James,
Your recommended approach means
1. each time when I created a new user, I need to traverse all the nodes in the tree and add "read deny" this new user to the node.
Not *every* node, since the permissions will inherit, but probably more nodes than you want to deal with.
2. when I want to assign a folder to this user, I will go to delete all the "read deny"s to him in this folder's all upstream folders and all downstream folders.
Again, inheritance would make this easier.
3. each time I create a new folder, I need to add "read denys" of all the users of this system who shouldn't see this folder - I don't know how to retrieve this user list yet.
You can retrieve the list of users from the /users.
What we are building is a totally dynamic system, users can keep creating new users and new folders, each user has his/her own accessible folders. Do you think this approach is a feasible one? Thanks.
Yes, this is feasible. What we've done for our setup is make two "categories" of collections, public and private. Because our default permissions allow read access to everything for everyone, to make a section "private" you must explicity deny everyone access. Then you only grant access to the users/roles that need it for that section. Because permission inherit you only need to make the root folder a section private and everything under that folder becomes private as well.
For what you're working on it might make sense to enforce some default permissions. You can either do this through your UI or Content Interceptors/Event Listeners. You should be able to set something up so that anytime a new collection is created at a certain level it automatically gets a permission that denys read to everyone and grants read to the owner/someone else. That will lower your overhead for creating new folders.
-James
regards,
Jun
Ok, I think I understand the issue a bit better now.
What I'd recommend is you start with the largest group of users possible and work your way down. Start by granting read to authenticated on A. This will give all of your users read access to the entire tree, so you don't need to worry about that. For special cases, such as Carl, you'll need to modify the permissions further down. Grant Carl write access to C1 and deny him read access to B2. The consequence of the way inheritance works in Slide is that you're going to have a lot of "deny" permissions to keep people out of certain areas.
-James
--------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages!
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------- Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
