[CalendarServer-users] Three questions about principals

Wilfredo Sánchez Vega wsanchez at wsanchez.net
Thu Dec 14 20:48:20 PST 2006

On Dec 9, 2006, at 11:09 AM, Cyrus Daboo wrote:

> Whilst there may not be "humans" directly posing as a group or a  
> resource, and "automated system" might. e.g,. a meeting room has a  
> little hardware device with LCD screen on its door. This device is a  
> calendar client that displays the current bookings for the room by  
> accessing the CalDAV calendar for the resource. The device is  
> programmed to login as the resource.
> (I've actually seen hardware devices like that, though they did not  
> have CalDAV support).

   I was talking to David about this recently...  In our  
implementation, there isn't actually any way to authenticate (via  
HTTP) as a non-user principal.  You will be able to authorize as such  
using the über-user (we need to call that something other than proxy,  
which already means something else) and X-Authorize-As.

   Changing this would require that you enter something more  
complicated than your user name into an HTTP auth dialog, for example.

   I think this is fine, though, once we add the planned proxy (that  
other meaning) groups, since you can add a user principal to the write  
proxy group for a non-user principal and then do the things you need  
to do.

>> Is there a way to configure the repository, so that anonymous  
>> access is
>> allowed (to make some public calendars accessible to anyone) but  
>> without
>> exposing the identities of all users and groups through the / 
>> calendars/
>> and /principals/ hierarchies?
> You can edit repository.xml to include a "/calendars/public"  
> hierarchy and add DAV:all, DAV:read inheritable privileges for that.  
> Note that you could use WebDAV protocol to create the collection and  
> set the ACLs via a client, but the "inheritable" option is a private  
> extension we have and not exposed.

   We've kill off repository.xml, so that's no longer an option.   
Frank filed a ticket on that:


   Anonymous users should be able to edit the calendars also?  If not,  
who gets to?  Absent any agents which let you set ACLs over the wire,  
we probably want some useable defaults here.


More information about the calendarserver-users mailing list