Hi, Krishna!

You are welcome.
Actually the org.apache.slide.util.XMLValue class helps me to handle
properties which values are XML element lists. You might try to use it as
well.

Yours sincerely,
Andrey.

> -----Original Message-----
> From: Slide Users Mailing List [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, August 05, 2004 2:00 PM
> To: [EMAIL PROTECTED]
> Subject: RE: User Authorization based on permissions set to 
> role in Slide2 .1
> Importance: Low
> 
> Andrey,
>       I ran a few tests using DAVExplorer0.9 to asssign users 
> to role and check if the permissions are propogated, and 
> looks like it works if I use the syntax for the 
> group-member-set property value as you mentioned. Using CDATA 
> section for the property value is highly mis-leading, since 
> it seems like it works but does not let the permissions 
> propogate (althoug the property is set right and you can also 
> view the property right). So, using CDATA section for any XML 
> property value is Slide is dangerous. Better use the XML 
> escape tags like '<'
> 
> Now I will try to update my java code to use the xml escape 
> tags instead of CDATA, I think it will work OK. 
> 
> Thanks for all the help, you really saved my day, you are my hero !!!!
> 
> regards,
> Krishna
> 
> 
> 
> -----Original Message-----
> From: Andrey Shulinsky [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 04, 2004 6:13 PM
> To: 'Slide Users Mailing List'
> Subject: RE: User Authorization based on permissions set to role in
> Slide2 .1
> 
> 
> Krishna, try to remove /Slide
> Here's how this property should look like in the xml descriptor
> (approximately):
> 
>         <property name="group-member-set" namespace="DAV:"
> value="&lt;D:href
> xmlns:D=&quot;DAV:&quot;&gt;/users/user1&lt;/D:href&gt;" type=""
> protected="false">
>           <permissions />
>         </property>
> 
> ' symbol might not be replaced by &quot; but the user's uri 
> should start from /users.
> 
> Yours sincerely,
> Andrey Shulinskiy.
> 
> > -----Original Message-----
> > From: Slide Users Mailing List 
> [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, August 04, 2004 7:54 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: User Authorization based on permissions set to role in 
> > Slide2 .1
> > Importance: Low
> > 
> > James,
> >     Here is the output of the group-member-set property of the role 
> > "user". Note the value has lot of empty and tab spaces
> > 
> > 
> >                     /Slide/users/user1
> >                 
> > 
> > Java code used to get this property value 
> > ==============================================================
> > ==============
> > ===================
> > String sPropertyName = "group-member-set"; Enumeration 
> enumProperties 
> > = webDavResource.propfindMethod(sPropertyName);
> > 
> > ==============================================================
> > ==============
> > =====================                               
> > 
> > Krishna
> > 
> >                     
> > 
> > -----Original Message-----
> > From: James Mason [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, August 04, 2004 4:57 PM
> > To: Slide Users Mailing List
> > Subject: Re: User Authorization based on permissions set to role in
> > Slide2 .1
> > 
> > 
> > Can you paste the contents of the group-member-set property of the 
> > user role? If you notice the root user doesn't have any explicit 
> > rights to the /files node, everything is inherited through the root 
> > role. My guess is your user isn't making it into the role properly.
> > 
> > -James
> > 
> > Krishna Kankipati wrote:
> > 
> > > Jason,
> > >   I checked the acl for this folder, it looks like this:
> > > 
> > > ACL for /Slide/files/folder1:
> > > ------------------------------------------------------------
> > > granted to /Slide/roles/user    (not protected)   (not inherited)
> > >    DAV:all
> > >    DAV:write
> > > granted to property    (not protected)   (inherited from 
> > '/Slide/files')
> > >    DAV:read-acl
> > > granted to /Slide/roles/root    (not protected)   (inherited from
> > '/Slide/')
> > >    DAV:all
> > > granted to all    (not protected)   (inherited from '/Slide/')
> > >    DAV:read
> > > ------------------------------------------------------------
> > > 
> > > I added my user 'user1' to role called 'user' using
> > group-member-set
> > > property (also checked it). Since the role 'user' has the
> > permissions
> > > to write to folder 'folder1', as seen by the ACL output, 
> and there 
> > > seems to
> > be
> > > no contradiction to any other ace's in the acl list, I 
> expected my 
> > > user 'user1' to have necessary permissions to upload a file to 
> > > 'folder1'. But
> > I
> > > get 403 forbidden error. I can login as root and  using the same 
> > > command
> > can
> > > upload a file to 'folder1'. So, I am not sure whats wrong. 
> > Initially I
> > > thought may be the group-member-set is not set properly, so used
> > DAVExplorer
> > > to do the same with no avail. Do you think I am missing
> > something, how
> > > do
> > I
> > > debug this situation?
> > > 
> > > 
> > > thanks,
> > > 
> > > regards,
> > > Krishna
> > > 
> > > 
> > > 
> > > -----Original Message-----
> > > From: James Mason [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, August 04, 2004 2:34 PM
> > > To: Slide Users Mailing List
> > > Subject: Re: User Authorization based on permissions set 
> to role in
> > > Slide2.1
> > > 
> > > 
> > > Krishna,
> > > Permissions on a role are inherited by the members of that
> > role, yes. 
> > > One thing to check is that your user isn't being denied
> > write access
> > > but another ACL that's higher in the list. ACLs are checked
> > in order
> > > and the first one that applies takes precedence. If user1
> > is in a role
> > > that has been denied the ability to write, and that ACE
> > appears in the
> > > ACL before the permission that grants write access, user1 
> will not 
> > > have write
> > access.
> > > 
> > > -James
> > > 
> > > Krishna Kankipati wrote:
> > > 
> > > 
> > >>Hi Folks,
> > >>  I am re-posting this mail since I haven't got any
> > replies yet. I am
> > >>hoping there is some developer there who might have tried to play 
> > >>around with permissions in Slide2.1M1. My problem is that when I 
> > >>assign some permissions to a role, those permissions are not 
> > >>propogated to the users
> > > 
> > > in
> > > 
> > >>that role. If not for permissions what else is the 
> purpose of having
> > roles
> > >>at all? I am sure it is not just for logical grouping of 
> users. Any 
> > >>help
> > > 
> > > is
> > > 
> > >>appreciated ......
> > >>
> > >>thanks in advance ....
> > >>
> > >>regards,
> > >>
> > >>Krishna
> > >>
> > >>
> > >>
> > >>
> > >>>-----Original Message-----
> > >>>From:    Krishna Kankipati  
> > >>>Sent:    Tuesday, August 03, 2004 5:47 PM
> > >>>To:      '[EMAIL PROTECTED]'; 
> > [EMAIL PROTECTED]
> > >>>Subject: User Authorization based on permissions set to role in
> > >>>Slide2.1
> > >>>
> > >>>Michael,
> > >>> I was searching the mail archive for some help on
> > permissions and
> > >>>came upon this discussion you were having with some 
> developer which
> > seemed
> > >>>relevant to my question:
> > >>>http://www.mail-archive.com/[EMAIL PROTECTED]/m
> > sg05056.ht
> > >>>ml
> > >>> 
> > >>>Does slide permissions propogate based on role
> > memberships. I mean,
> > >>>if I create a role called "role1", and add a user called
> > "user1" to
> > >>>it, will
> > >>>user1 get all the permissions that are assigned to role1. 
> > I've seen
> > >>>in
> > my
> > >>>tests that although I gave enough "write" permissions to 
> "role1", 
> > >>>Slide does not allow "user1" to write unless I add the "write"
> > >>>permission to "user1" itself. Am I missing something or is
> > it a bug. 
> > >>>What is your opinion on this? I am using Slide 2.1M1 and
> > command line
> > >>>client to grant permissions to /Slide/files collection.
> > >>>
> > >>>thanks
> > >>>
> > >>>regards,
> > >>>Krishna
> > >>>
> > >>>
> > >>>Krishna Kankipati
> > >>>Software Engineer
> > >>>SSA Global
> > >>>*       1626 Cole Blvd. Golden, CO 80401, USA
> > >>>*  303-274-3027
> > >>>Fax:    303-274-3137
> > >>>*  [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]

Reply via email to