DAV:current-user-privilege-set

The DAV:current-user-privilege-set WebDAV ACL property allows a client application to know what operations the currently authenticated user can issue on a WebDAV resource (read, read-write, etc...).

Until now, I was under the impression that servers should return only the top level privileges (aggregate or not).

For example, given a server with the following supported set (note that DAV:all is not abstract):

 [DAV:, all] (aggregate)
      |
      +-- [DAV:, read] (aggregate)
             |
             +-- [DAV:, read-acl] (abstract)
             +-- [DAV:, read-current-user-privilege-set] (abstract)
      |
      +-- [DAV:, write] (aggregate)
             |
             +-- [DAV:, write-acl] (abstract)
             +-- [DAV:, write-properties]
             +-- [DAV:, write-content]

and a user with all rights on a resource,  I was expecting the following DAV:current-user-privilege-set:

 <D:current-user-privilege-set>
    <D:privilege><D:all/></D:privilege>
 </D:current-user-privilege-set>

But the WebDAV ACL specification clearly states that "Aggregate privileges and their contained privileges are listed". So what the server should return is really the full set:

 <D:current-user-privilege-set>
    <D:privilege><D:all/></D:privilege>
    <D:privilege><D:read/></D:privilege>
    <D:privilege><D:write/></D:privilege>
    <D:privilege><D:write-properties/></D:privilege>
    <D:privilege><D:write-content/></D:privilege>
 </D:current-user-privilege-set>

I guess this makes client implementers life easier.


Comments:

> I guess this makes client implementers life easier

Yes. And it bumps the XML response size a LOT. We do not request it anymore, not worth the effort except for collections :-/

hh

Posted by Helge Heß on November 07, 2009 at 04:42 PM CET #

Computing this property can be quite expensive on the server side, especially when the calculation involves ACEs granted to LDAP groups or inherited ACLs,...

As a consequence, what you are currently doing (not asking for it when issueing a PROPFIND with Depth=1 or a CalDAV report) could probably be a listed as a best practice.

Posted by Arnaud Quillaud on November 09, 2009 at 07:39 AM CET #

Well, yes, but technically the client (better) needs to know about the permissions on individual items to present the respective status to the user. Its just that the current mechanism is too expensive.

But then the concept is flawed for the client anyways, since the access control is in WebDAV properties, hence the client can't detect changes via ETags. Big issue IMHO.

Posted by Helge on November 09, 2009 at 04:14 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
About

arnaudq

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks