Hello Girish,
I want to add some things regarding your XML snippets:
<objectnode classname="org.apache.slide.structure.SubjectNode" uri="/files/girish">
<permission action="all" subject="/user/gn" inheritable="true"/>
<permission action="/actions/write" subject="/user/john" inheritable="true"/>
<permission action="/actions/read-acl" subject="/user/john" inheritable="true"/>
</objectnode>
Where "gn" was a user I defined in the domain.xml
<objectnode classname="org.apache.slide.structure.SubjectNode" uri="/users/gn">
<revision>
<property namespace="http://jakarta.apache.org/slide/";
name="password">gn</property>
</revision>
</objectnode>
You create a user "/users/gn" but in the permissions of the object node you refer to user
"user/gn". The same applies for "/user/john".
For "john" having write access he also needs explicitely given read access. But I guess that the
read access is given in a superior node of "/files/girish".
With this setup, I can't login with gn/gn nor does using john2/john2
prevents me from creating a subfolder under /files/girish.
I cannot see any permission for "/users/john2".
Is it possible to setup authenication so that "writing" to certain
folders are allowed to only the specified users?
Yes it is possible. If you want to restrict write access on a certain folder to a
certain user then do something like this:
1. Make sure the user is given read access (somewhere in a superior node, inheritable).
2. Explicitely grant write access to that special user.
3. Deny write access to everybody else.
Example:
...
<objectnode classname="org.apache.slide.structure.SubjectNode" uri="/files">
<permission action="read" subject="all" inheritable="true"/>
<objectnode classname="org.apache.slide.structure.SubjectNode" uri="/files/john">
<permission action="write" subject="/users/john" inheritable="true"/>
<permission action="write" subject="all" inheritable="true" negative="true"/>
</objectnode>
</objectnode>
...
The strategy for evaluating the ACLs is to find the first entry which matches the
current user and the action to be executed. If /users/john would try to write on
/files/john then the first entry would match. Because this entry is not negative the
action would be permitted. After having found this matching entry no further ACL
entries are evaluated. As another user the first ACL entry doesn't match. So the next
entry is checked. This applies to all users and denies the write access. So this the
other user would not be permitted to write.
The helpers do not distinguish whether a read operation was initiated by another
helper or by a WebDAV request. Therefore read access is needed because the Slide
helpers perform read accesses to fulfill write operations and because giving write
access does not imply read access.
Regards,
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
