You are right, only users and roles created at domain init time get DAV:principal as resourcetype *automatically*. And you are right that the ACL spec doesn't cover user DB maintenance (e.g. there is no method MKPRINCIPAL or the like). Note aside: we had the same problem, as we wanted being able to create users via WebDAV in Tamino WebDAV Server ... and we decided to use MKCOL, as you are proposing.
Now, as DAV:resourcetype is a protected property, the client has no chance to proppatch the resourcetype with DAV:principal after the MKCOL. So, as you suggests, Slide should automatically set the resourcetype DAV:principal for any *resource* created inside the collections <userspath>/ or <rolespath>/. For example, resources created at /users/a, /users/b, /roles/xyz will automatically become *principals*. Would that be OK for you, Jacob? Regards, Peter > -----Original Message----- > From: Jacob Lund [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 20, 2004 11:24 > To: 'Slide Users Mailing List' > Subject: RE: group-membership and latest slide > > > How is DAV:principal added to DAV:resourcetype? Users added in the > domain.xml file are fine, but if I create a user using mkcol > and proppatch, > then the DAV:principal is missing. > > I believe slide does not allow users to be placed in > collections - should > all collections in the userspath be principals or do > collections make sense > in the userspath? > > Is there a way to create users using the webdav interface? I > know it is not > a part of the standard, but it was possible before! > > /Jacob > > -----Original Message----- > From: Nevermann, Dr., Peter [mailto:[EMAIL PROTECTED] > Sent: 17. januar 2004 22:49 > To: Slide Users Mailing List > Subject: RE: group-membership and latest slide > > OK, the fixes are checked-in now. > > Regards, > Peter > > > -----Original Message----- > > From: Nevermann, Dr., Peter [mailto:[EMAIL PROTECTED] > > Sent: Friday, January 16, 2004 19:42 > > To: Slide Users Mailing List > > Subject: RE: group-membership and latest slide > > > > > > > From: Jacob Lund [mailto:[EMAIL PROTECTED] > > > Sent: Friday, January 16, 2004 12:03 > > > > > > I was looking at the latest ACL implementation and I have > > > some problems with > > > DAV:group-membership. On a principal uri this property should > > > contain the > > > groups in which a user is a member of. (Referring to section > > > 4.4 in the ACL > > > draft 12). > > > > OK, that's a bug - thanks for reporting. I fixed it but will > > check-in on Monday, because I hadn't time to run the > > testsuite yet. Also, DAV:principal was missing in > > DAV:resourcetype of principal resources. > > > > > I am not sure about this because we are talking about groups > > > and not roles. > > > I am using the default domain.xml for testing - I tried to > > convert the > > > default roles to groups, but that did not change anything. > > When I do a > > > propfind on a user uri for DAV:group-membership, then I get a > > > 404 response. > > > > The ACL standard only has one notion of a grouping principal, > > being a principal which can contain other principals. You > > might have noticed that in the Slide impl there is a > > groupsPath and a rolesPath (we needed both for Tamino). I > > suggest that we use the term "role" in Slide, as it is closer > > to Tomcat and what we had before in Slide. So, you might > > ignore "groups" (do not define groupsPath in Domain.xml) and > > let a role be the type principal which can contains other > > principals (users or roles). > > > > Regards, > > Peter > > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
