Comments below.

Carlos Villegas wrote:

Hi,

I've been doing some tests with ACLs and it seems to me that write privilege implies write-acl. Is that the way is suppose to be?
I'm using the Slide 2.0 release.

This is the way it's supposed to be. Take a look at the <data> section of your Domain.xml file. You'll see that many of the /actions nodes are composites of other nodes. This means many /actions, such as read, write and all, are really shortcuts so that you don't have to assign six different capabilities just to get the standard behavior.



For example, given the following ACL on the files collection:

ACL for /slide/files/:
------------------------------------------------------------
denied to unauthenticated (not protected) (inherited from '/files')
DAV:all granted to /roles/user (not protected) (inherited from '/files')
DAV:write granted to property (not protected) (inherited from '/files')
DAV:read-acl granted to /roles/admin (not protected) (inherited from '/')
DAV:all denied to all (not protected) (inherited from '/')
DAV:read-acl DAV:write-acl DAV:unlock granted to all (not protected) (inherited from '/')
DAV:read A user (having role user) is returning write-acl in the property current-user-privilege-set.
However, read-acl is not present as expected. Indeed I was able to modify the ACL even though I couldn't read it !
To get what I'd expect to be the right behaviour, I need to add a deny write-acl ACE above the grant write ACE so it takes precedence.
If this is the correct behaviour, then read and read-acl work the same way. In fact, in the above ACL, deny read-acl overwrites the previous grant read privilege.


There seems to be some bug on writing ACLs through the command line client. But I think it's a different issue. Sometimes all the non-inherited ACEs are deleted when I issue a grant command and afterwards only the one granted remains.

Which version of the client and server are you using? There was a bug in the server that could cause this, but it should be squashed in the latest release (2.1b1).




BTW, I added to following methods to the client CurrentUserPrivilegeSetProperty class:

public boolean hasReadAclAccess() {
NodeList readPrivilege = DOMUtils.getElementsByTagNameNS(getElement(), "read-acl", "DAV:");
return (readPrivilege.getLength() == 1);
}


public boolean hasWriteAclAccess() {
NodeList writePrivilege = DOMUtils.getElementsByTagNameNS(getElement(), "write-acl", "DAV:");
return (writePrivilege.getLength() == 1);
}


public String getPropertyAsString() {
String theResult="";
theResult = (hasReadAccess()) ? "Read" : theResult;
theResult = (hasWriteAccess()) ? theResult+" Write" : theResult;
theResult = (hasReadAclAccess()) ? theResult+" ReadACL" : theResult;
theResult = (hasWriteAclAccess()) ? theResult+" WriteACL" : theResult;
return theResult.trim();
}


Need to add others or maybe is better to add a generic method like hasPrivilege(String privilegeName) instead.

The generic method would probably be better, but I haven't really looked at it so don't take me too seriously here :).


-James


Carlos

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to