Hi all,
I’ve been trying to use the ACL support in the latest version of the webdav server (4.1.5). We have it set up to use LDAP (Active Directory) for security.
I wanted to use the principal-property-search REPORT method to search for appropriate principals to use in the ACLs. However, I encountered some problems:
Firstly, the documentation for 4.1.5 says that it implements draft 08 of the ACL specification. However (at least for principal-property-search) it actually implements draft 07 - the syntax of this report request changed between the two versions, so I got errors using the documented one.
Secondly (and more seriously): when I changed to creating REPORT requests using the -07 draft, the response was always empty (i.e. the element contained zero , even when I was searching for something I knew existed. I was searching (-07 specifies all searches as case insensitive substring searches) for some substring in the displayname (I also tested exact matches, it made no difference).
Doing a propfind for displayname directly on the relevant URL worked, so the properties are there.
Can anyone give me an example of how to do this successfully?
Thanks in advance,
Michael
Hi Michael,
I use a principa-property-search that determines the displayname of all principals. It works again Tamino WebDAV 4.1.5 and LDAP. I appended a trace of the method.
Martin
-----------------------------------------
REPORT /taminowebdavserver/files/martin/sundnDemo/ HTTP/1.1
Authorization: Basic bWR1bGlzY2g6bWR1bGlzY2g=
User-Agent: Jakarta Commons-HttpClient/2.0rc1
Host: localhost:7000
Cookie: $Version=0; JSESSIONID=E7F8FF378A5D69641F7E00DADB5946FF; $Path=/taminowebdavserver
Content-Length: 241
Content-Type: text/xml; charset=utf-8
Depth: infinity
<?xml version="1.0" encoding="utf-8" ?>
<D:principal-property-search xmlns:D=“DAV:”>
<D:property-search>
<D:prop><D:displayname/></D:prop>
<D:caseless-substring/>
</D:property-search>
<D:prop><D:displayname/></D:prop>
</D:principal-property-search>
-----------------------------------------
Michel,
I just have seen in your other post that you use the new support for groups in TWS 4.1.5. When we turn on this feature the principal-property-search does not work too.
Martin
Hmmmm, good to know. We are going to switch to LDAP managed users soon, too. Still on the older TWS release, though. But knowing this we still can’t expect the principal-property-search REPORT to work. Too bad …
Regarding the syntax of the request: I’ve experienced the exact same phenomenon. Even though I specified the REPORT request as described in drafts -08 through -10 it didn’t work. Then finally trying one further step back to -07 the request itself went through, but the result was empty.
I wish there was some documentation on the status of implementation of the WebDAV ACP protocol in TWS.
Does anyone know of something I’m not aware of?
Guy
The principal-property-search works now for us with TWS 4.1.5 and groups activated.
The proplem was a inconsistent LDAP user database. We had users in groups which did not exist. The result was a “Bad Request” response.
Martin
Hi Michael,
to answer your first question, you are right, TWS implements the ACL draft 7. For the principal-property-search Report it does mean that <D:caseless-substring> has to be used instead of <D:match>.
As second, in the case the response is always empty sounds like you are searching with a depth of 0 (default). Try to change the depth parameter in the HTTP method header to ‘Depth: infinity’ (see the sample below). As default ‘Depth: infinity’ would mean a depth of 3. You can change this infinity default by changing the depth-limit in the web.xml file under Tamino WebDav Server 4.1.5\taminowebdavserver\WEB-INF. Hope it helps,
kind regards,
Eckehard Hermann
Software AG R&D
Sample:
REPORT http://localhost:4000/taminowebdavserver/administration/security/userdb/groups/group2 HTTP/1.1
Authorization: Basic XXXXXX
Host: localhost:4000
Content-length: 280
Depth: infinity
<?xml version="1.0" encoding="utf-8" ?>
<D:principal-property-search xmlns:D=“DAV:”>
<D:property-search>
<D:prop>
<D:displayname/>
</D:prop>
<D:caseless-substring>group2</D:caseless-substring>
</D:property-search>
<D:prop>
<D:displayname/>
</D:prop>
</D:principal-property-search>
Eckehard,
This enables me to get further, but still doesn’t work. However, it shouldn’t be needed. Quoting from the draft-07 specification:
“The DAV:principal-collection-set property of the resource identified by the Request-URI specifies the scope of the DAV:principal-property-search REPORT, as follows:
- All principal and collection principal resources identified in DAV:principal-collection-set are searched
- All principal and collection principal resources that are descendents of a collection principal resource identified in DAV:principal collection-set are searched.”
So the depth header shouldn’t matter, since what is being searched is something OTHER than the request URI.
Interestingly, although you said Depth: infinity is equivalent to Depth: 3 (and I haven’t changed the depth-limit in web.xml), this doesn’t happen with Depth: 3 (that just has the same effect as no depth header: zero responses).
However, with Depth: infinity, I get a 400 Bad Request response, as follows:
Bad Request: Service com.softwareag.xtools.xdav.util.security.SimpleGroupSecurityStore@57b46f access error : Conflict with uri /administration/security/userdb/groups/Exchange Domain Servers/DMS2000. Cause is: access is forbidden
I’m not sure why this was causing an error.
Michael