hi remy,
I am running the catalina server and the slide command line example
Slide.java on the client side.
The data in my Domain.xml file looks this
<data>
<objectnode classname="org.apache.slide.structure.SubjectNode"
uri="/">
<permission action="/actions" subject="root"/>
<permission action="/actions/read" subject="user"
inheritable="false"/>
<permission action="/actions/read" subject="nobody"
inheritable="false"/>
<!-- /users represents the unauthenticated user -->
<objectnode classname="org.apache.slide.structure.SubjectNode"
uri="/users">
<permission action="/actions" subject="~"/>
<permission action="/actions" subject="guest"
inheritable="true" negative="true"/>
<permission action="/actions/read" subject="user"
inheritable="false"/>
<!-- Permission group example -->
<objectnode classname="org.apache.slide.structure.GroupNode"
uri="/users/groupA">
<objectnode classname="org.apache.slide.structure.LinkNode"
uri="/users/groupA/john" linkedUri="/users/john" />
<objectnode classname="org.apache.slide.structure.LinkNode"
uri="/users/groupA/root" linkedUri="/users/root" />
<objectnode classname="slideroles.basic.UserRoleImpl"
uri="/users/groupA/singleGroupMember" >
<revision>
<property name="password"
namespace="http://jakarta.apache.org/slide/";>single</property>
</revision>
</objectnode>
</objectnode>
<!-- /users/root represents the administrator -->
<objectnode classname="slideroles.basic.RootRoleImpl"
uri="/users/root">
<!-- Uncomment and change the password to allow login as root to
edit the namespace -->
<revision>
<property name="password"
namespace="http://jakarta.apache.org/slide/";>root</property>
</revision>
</objectnode>
<!-- /users/john represents an authenticated user -->
<objectnode classname="slideroles.basic.UserRoleImpl"
uri="/users/john" >
<revision>
<property name="password"
namespace="http://jakarta.apache.org/slide/";>rajk75</property>
</revision>
</objectnode>
<!-- /users/guest represents an authenticated or unauthenticated
guest user -->
<objectnode classname="slideroles.basic.GuestRoleImpl"
uri="/users/guest" />
</objectnode>
<objectnode classname="org.apache.slide.structure.ActionNode"
uri="/actions">
<objectnode classname="org.apache.slide.structure.ActionNode"
uri="/actions/read"/>
<objectnode classname="org.apache.slide.structure.ActionNode"
uri="/actions/write"/>
<objectnode classname="org.apache.slide.structure.ActionNode"
uri="/actions/manage"/>
</objectnode>
<objectnode classname="org.apache.slide.structure.SubjectNode"
uri="/files">
<!-- ### Give read/write/manage permission to guest ###
Uncomment the following line to give permission to do
all actions on /files to guest (unauthenticated users) -->
<!-- <permission action="/actions" subject="/users/guest"/> -->
<permission action="/actions/manage" subject="/users/john"/>
<permission action="/actions/write" subject="+/users/groupA"/>
<permission action="/actions/read" subject="nobody"/>
</objectnode>
</objectnode>
</data>
When i give a command like acl files on the client side i output that i get
is as follows.
ACL for /files:
------------------------------------------------------------
granted to /users/john (not protected) (not inherited)
DAV:read-acl
DAV:write-acl
granted to /%2B/users/groupA (not protected) (not inherited)
DAV:write
granted to all (not protected) (not inherited)
DAV:read
granted to /root (protected) (inherited from '/')
DAV:all
------------------------------------------------------------
The last access control entry says granted to /root .Does this mean granted
to any user with the role root(class of that subject node implements the
RootRole interface ) or is there is special user /root who is granted access
to all privileges.
thanks,
rajkumar
-----Original Message-----
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 17, 2001 6:25 PM
To: [EMAIL PROTECTED]
Subject: Re: admin-webapp - user management
> Okay, I'm getting ready to commit parts of the taglib to the repository...
> src/taglib is okay for that, right ?
Yes.
> Regarding the upcoming release, my priority is getting the taglib working
for
> the admin-webapp. That means that the taglib is mostly targeted at the
> requirements of the admin-webapp, and it is very likely that the taglib
itself
> will still (r)evolve quite a bit (before and probably even after 1.0
final). I
> believe we can declare the taglib "API" to be in an early stage, but still
> include it with the release while making sure it is in sync with the admin
> webapp.
Yes, that's reasonable, and we'll mention it in the release notes. I think
we should plan to stabilize that new API when we start freezing for the next
release.
Remy
