Hi Protecting the server configuration is needed, a misconfigured domain.xml can do a lot of damage.
The more flexible configuration is one of the features of slide. http://jakarta.apache.org/slide/namespace.html I never used it myself and it is quite possible that there are problems with it. It also adds a lot of complexity to the slide engine (multiple serverces, transactions,...) maybe it is not worth it or maybe we should delegate this functionality to a higher (servlet container) or lower (backend store) level. Testing these configurations is not a priority for me, I only use one scope for each domain. It is a good way to start digging into the lower levels of slide if you have the time. Dirk "Hermann, Eckehard" wrote: > > Hi Dirk, > > o.k., I had a look into the ACL standard and you are right, a principal has > to be a webdav resource and so in slide we will need the userpath. My > example/trick with changing the userpath should just demonstrate that it is > possible to change the access rights without having write-acl permission. > But however the webdav (slide) admin has to spend special care to the > Domain.xml file for protecting it against unauthorized userpath > manipulation. > > I had problems with your 'more flexible configuration' example. I didn't get > it to run. Is it a planned or implemented feature? > > I think the standard says something about how to manage groups (principal > collections) and principals. In case of a principal the DAV:resourcetype > property should report DAV:principal. A collection principal should report > DAV:principal and DAV:collection. > > regards Eckehard -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
