Monday Nov 02, 2009

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.


Friday Mar 13, 2009

URI encoding in DAV:href element

The DAV:href xml element, defined in the WebDAV specification is used in many request/response payloads and DAV properties. It is important to note that the element value is a URI as defined in RFC3986.

As such, this value must be percent encoded if it contains characters outside the allowed range. When clients and server misinterpret this requirement, things can get messy. Here is some illustration:

If a calendar client knows about the principal collection of a user, it can retrieve the CalDAV calendar-home-set property of the user:

PROPFIND /dav/principals/johnd/ HTTP/1.1
host: dav.example.com
content-type: text/xml
content-lengh: xxx
depth: 0

<?xml version="1.0" encoding="utf-8"?>
<D:propfind xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:D="DAV:">
 <D:prop>
  <C:calendar-home-set/>
 </D:prop>
</D:propfind>

In this case, the calendar home was identified internally as '/dav/home/John.Doe@example.com/'. Our server was sending the following response:

HTTP/1.1 207 Multistatus
Date: xxx
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>/dav/principals/johnd/</D:href>
    <D:propstat>
      <D:prop>
        <C:calendar-home-set><D:href>/dav/home/John.Doe%40example.com/</D:href></C:calendar-home-set>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

(Once percent encoded, the '@' character becomes '%40').

Using the returned calendar-home-set, the client would then get the list of calendars under this calendar home by issuing a Depth=1 PROPFIND query. But it would re encode the returned URI, resulting in a:

PROPFIND /dav/home/John.Doe%2540example.com/ HTTP/1.1

The client encoded '%' as '%25' and the server was interpreting the request as targeting a collection identified internally as /dav/home/John.Doe%40example.com/ which of course did not exist.

As it turned out, the '@' character is a reserved character but it is one of the few reserved characters allowed in the path component of a URI. So our server probably should not have encoded it in the first place.

But given that the URI was already encoded, the client should have either send it as is (i.e. without the need to either decode or reencode it):

PROPFIND /dav/home/John.Doe%40example.com/ HTTP/1.1

or with the '@' character decoded:

PROPFIND /dav/home/John.Doe@example.com/ HTTP/1.1

It looks like there are other cases of client/server misinterpreting those URIs.

Thursday Mar 15, 2007

Los Caracoles

As a full time work from home employee, I tend to have quick lunches (i.e. a piece of cheese + bread) in front of my computer. Summer is almost there in downtown Montpellier. So in order to save my computer's keyboard (from crumbs), I'll start to explore terraces in my neighborhood. Since this is somehow work related (and since this blog had a "Personal" category when I opened it), I'll try to keep track of them.

 I started today with Los Caracoles, on Place Laissac which is 50 meters from my place:

Terrace is in the sun for all of the lunch hours. Place Laissac is pretty quiet.

Paid 16€ for a Tapas "combo" + wine/coffee so this won't become my canteen but everything was fresh and I enjoyed the meal while reading the quite indigestible Versioning Extensions to WebDAV.

Service was fast.
 

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