Kevin,
Roles & LDAP
Yep, you need to define the roles within SLIDE. They need to match your LDAP
roles otherwise there is no context for SLIDE to base itself on.
Roles & Users & Domain.XML
Absolutely right - Domain.XML is only used to initialise. What you see with the
base examples are the user defs for that role. I haven't had to do any dynamic
changing of the roles but I suspect that if you carry the role through from the
LDAP environment you may not have to do this dynamic change at all. The user is
associated with the role. The role is associated with the permissions. I
haven't tested this but that would be my gut feel. Others may be able to answer
this for you/us.
Dynamically associating roles.
Again I haven't had to do this, but since the permissions are properties of the
folder I would think a simple call to change/add/remove the role from the
property should sort that out. If you can't do it directly through a WebDAV
call then grab the XML and do it through that.
Hth
Phil
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thu 21/07/2005 17:23
To: Slide Users Mailing List
Cc:
Subject: RE: acl question
I think you are right. I have not defined any roles within Slide. It
sounds like the roles in Slide need to match the roles in LDAP. In
looking
at the /roles in domain.xml do you need to define each user in the role
like the following? I could have a few thousand users that keep getting
added as the project moves forward.
<objectnode classname="org.apache.slide.structure.SubjectNode"
uri="/roles/user">
<revision>
<property name="group-member-set"><![CDATA[<D:href
xmlns:D='DAV:'>/users/john</D:href><D:href
xmlns:D='DAV:'>/users/john2</D:href><D:href
xmlns:D='DAV:'>/users/root</D:href><D:href
xmlns:D='DAV:'>/users/projector</D:href>]]></property>
</revision>
</objectnode>
I am uploading files (putmethod) and creating directories (mkcol) with
my
application, how do I dynamically add directories with roles like in the
domain.xml b/c I think the domain.xml is only used at init?
For each file I put on the server it creates a file/directory structure
something likes this:
xx/yy/zz/xx_yy_zz_state.jpg
xx/yy/zz/THUMBNAIL/xx_yy_zz_state.jpg
"Burnside,
Phillip \(UK -
Glasgow\)"
To
<phillipburnside@ "Slide Users Mailing List"
deloitte.co.uk> <slide-user@jakarta.apache.org>
cc
07/21/2005 03:59
AM
Subject
RE: acl question
Please respond to
"Slide Users
Mailing List"
<[EMAIL PROTECTED]
ta.apache.org>
Kevin,
Without seeing the entire Domain.XML I'm guessing a bit, but I would
suspect that you haven't defined the specific role permissions on the
store.
Although you have defined the roles in JNDI you haven't defined them in
SLIDE nor have you set specific permissions for them on the store.
I have included a code snippet to show you what I mean. In the snippet I
have previously defined a role '/roles/data1' and now exclude it from
the
folder 'marketing'. This blocks any user with the role from writing to
the
'marketing' folder or any sub-folders. I then explicitly allow
'/users/user3' permission to write to '/marketing/gadgets'.
Hth
Phil
<objectnode
classname="org.apache.slide.structure.SubjectNode"
uri="/">
<!-- Subject can be: any user
"all" authenticated user "authenticated"
unauthenticated user "unauthenticated" self
"self" owner of resource "owner" a user
"/users/john" a role "/roles/admin"
-->
<permission action="/actions/read-acl" subject="all"
inheritable="true"/>
<permission action="/actions/write-acl" subject="all"
inheritable="true"/>
<permission action="/actions/unlock" subject="all"
inheritable="true"/>
<permission action="/actions/read" subject="all"
inheritable="true"/>
<permission action="/actions/write" subject="/roles/data1"
inheritable="true"/>
<permission action="/actions/bind" subject="/roles/data1"
inheritable="true"/>
<objectnode
classname="org.apache.slide.structure.SubjectNode" uri="/marketing">
<permission action="/actions/write" subject="/roles/data1"
inheritable="true" negative="true"/>
<permission action="/actions/bind" subject="/roles/data1"
inheritable="true"/>
<objectnode
classname="org.apache.slide.structure.SubjectNode"
uri="/marketing/widgets">
<permission action="/actions/read-acl"
subject="owner"
inheritable="true"/>
</objectnode>
<objectnode
classname="org.apache.slide.structure.SubjectNode"
uri="/marketing/gadgets">
<permission action="/actions/read-acl"
subject="owner"
inheritable="true"/>
<permission action="/actions/write" subject="/users/user3"
inheritable="true"/>
<permission action="/actions/bind" subject="/users/user3"
inheritable="true"/>
</objectnode>
</objectnode>
<objectnode
classname="org.apache.slide.structure.SubjectNode" uri="/accounts">
<objectnode
classname="org.apache.slide.structure.SubjectNode"
uri="/accounts/p_and_l">
<permission action="/actions/read-acl"
subject="owner"
inheritable="true"/>
<permission action="/actions/write" subject="/roles/data1"
inheritable="true" negative="true"/>
<permission action="/actions/bind" subject="/roles/data1"
inheritable="true"/>
</objectnode>
<objectnode
classname="org.apache.slide.structure.SubjectNode"
uri="/accounts/balance">
<permission action="/actions/read-acl"
subject="owner"
inheritable="true"/>
</objectnode>
</objectnode>
</objectnode>
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thu 21/07/2005 00:19
To: Slide Users Mailing List
Cc:
Subject: acl question
In my domain.xml I have setup permission such that under
"/"
all can
read-acl, write-acl, unlock and read (the default)
<permission action="/actions/read-acl" subject="all"
inheritable="true"
negative="true"/>
<permission action="/actions/write-acl" subject="all"
inheritable="true"
negative="true"/>
<permission action="/actions/unlock" subject="all"
inheritable="true"
negative="true"/>
<permission action="/actions/read" subject="all"
inheritable="true"/>
Under "/files" I have setup permission such that anyone
authenticated can
do anything, write if authenticated (although redundant I
think),
and the owner can read-acl (also redundant?)
<permission action="all" subject="authenticated"
inheritable="true"/>
<permission action="/actions/write"
subject="authenticated"
inheritable=
"true"/>
<permission action="/actions/read-acl" subject="owner"
inheritable="true"
/>
I am using the JNDIPrincipalStore for user and roles so
this
is all I have
in the domain.xml (default from the JNDI example):
<objectnode classname=
"org.apache.slide.structure.SubjectNode" uri="/users">
<permission action="all"
subject="self"
inheritable="true"/>
<permission action="all"
subject=
"authenticated" inheritable="true" negative="true"/>
</objectnode>
<objectnode classname=
"org.apache.slide.structure.SubjectNode" uri="/roles">
<permission action="all"
subject="self"
inheritable="true"/>
<permission action="all"
subject=
"authenticated" inheritable="true" negative="true"/>
</objectnode>
User A authenticates and writes file X to the WebDAV
server.
User B authenticates and changes the contents of file X on
the
server.
The problem is that user A and user B belong different
roles
and should not
be able to do this.
How or where do I define this restriction?
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
IMPORTANT NOTICE
If you have received this e-mail in error or wish to read our e-mail
disclaimer statement and monitoring policy, please refer to the
statement
below or contact the sender.
This communication is from Deloitte & Touche LLP. Deloitte & Touche
LLP
is a limited liability partnership registered in England and Wales with
registered number OC303675. A list of members' names is available for
inspection at Stonecutter Court, 1 Stonecutter Street, London EC4A 4TR,
United Kingdom, the firm's principal place of business and registered
office. Deloitte & Touche LLP is authorised and regulated by the
Financial Services Authority.
This communication and any attachments contain information which is
confidential and may also be privileged. It is for the exclusive use
of
the intended recipient(s). If you are not the intended recipient(s)
please
note that any form of disclosure, distribution, copying or use of this
communication or the information in it or in any attachments is strictly
prohibited and may be unlawful. If you have received this
communication in
error, please return it with the title "received in error" to
[EMAIL PROTECTED] then delete the email and destroy any copies
of it.
E-mail communications cannot be guaranteed to be secure or error free,
as
information could be intercepted, corrupted, amended, lost, destroyed,
arrive late or incomplete, or contain viruses. We do not accept
liability
for any such matters or their consequences. Anyone who communicates
with
us by e-mail is taken to accept the risks in doing so.
When addressed to our clients, any opinions or advice contained in this
e-mail and any attachments are subject to the terms and conditions
expressed in the governing Deloitte & Touche LLP client engagement
letter.
Opinions, conclusions and other information in this e-mail and any
attachments which do not relate to the official business of the firm are
neither given nor endorsed by it.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
