Calendar Proxy

• Calendar Proxy
• Introduction
• Client support
• Setting up
• Rolling your own
• Reference
• Final notes

Introduction

Since version 1.4 SabreDAV comes with a Calendar-proxy support. This feature allows for calendar delegation.

Calendar delegation allows users to give other people access to their calendars. This can be done either read-only or read-write.

Client support

iCal is the only client that fully supports this feature. You would however be able to manually add the permissions to the database and connect to other users' calendars.

It is not yet possible with iCal to grant permissions to other users, as iCal uses several non-standard features that don't appear to be documented anywhere.

So for the moment it's required to manually add delegees using the database, or by directly interfacing with the WebDAV API for this.

Once permissions are granted though, delegated calendars show up in the iCal preferences interface.

Setting up

If you're using Sabre_CalDAV_Server, you already have support. You can add new delegees through the accounts settings in iCal.

However, if you're creating new user accounts, you must add a few special entries to the 'principals' database table.

Example for creating a 'John Smith' account:

INSERT INTO users (username, digesta1) VALUES ('jsmith',MD5('jsmith:SabreDAV:mypassword'));
INSERT INTO principals (uri, email, displayname) VALUES ('principals/jsmith','jsmith@example.org','John Smith');

-- Now the special principals
INSERT INTO principals (uri) VALUES ('principals/jsmith/calendar-proxy-read');
INSERT INTO principals (uri) VALUES ('principals/jsmith/calendar-proxy-write');

If you ever want to manually add other uses as your delegees, you can do so by adding entries to the 'groupmembers' database table.

In short, John Smith now has 2 groups which it can manage. If it adds other users to these groups, these users are automatically granted access in read-only or read-write fashion.

Rolling your own

If you're rolling your own, there's a few things you must keep in mind. First off, you should use the following classes for the principal tree:

• Sabre_CalDAV_Principal_Collection
• Sabre_CalDAV_Principal_User

and not:

• Sabre_DAVACL_PrincipalCollection
• Sabre_DAVACL_Principal

The reasons being, is that the calendar-proxy support requires a few special principals. The Sabre_CalDAV_Principal classes do this for you.

If you created your own 'Principal backend', also keep in mind that calendar-proxy-read and calendar-proxy-write groups must exist, and they must exist 'under' the user-principal in the tree.

Access is managed through group-membership.

Reference

This feature is based on the specification published here: http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/doc/Extensions/caldav-proxy.txt.

Final notes

This feature is pretty new, so we're testing the waters a little bit. Realizing this is a bit difficult to grasp, hopefully this API will become easier to use in the future.