[CalendarServer-users] Client library and admin tool

Scott Buchanan dscottbuch at mac.com
Fri Apr 4 10:03:00 PDT 2008


I was starting down this path already.  Re "WebDAV ACLs are overly  
complex for most of the operations people want to do" is quite an  
understatement :):)

One of my main problems seems to have been fixed in the 1_3 branch,  
which I just started using.  It appears in that branch that the main  
calendar of each principal is now 'locked' against delete by anyone by  
the Server by default therefore each groups 'calendar' is safe from  
accidental deletion.

Now I'm trying to find a description of how to add a  location  
principal (and resource principal) to a Tiger OD server.  Any place I  
can go here?  I assume I need to edit the scheme of the ldap,  
something I've never done.

Thanks for all your help.

On Apr 4, 2008, at 9:26 AM, Cyrus Daboo wrote:

> Hi Scott,
> --On April 4, 2008 8:19:03 AM -0700 Scott Buchanan  
> <dscottbuch at mac.com> wrote:
>> is the following consistent with your analysis?
>> HTTP/1.1 403 Forbidden
>> Date: Fri, 04 Apr 2008 15:17:32 GMT
>> DAV: 1, access-control, calendar-access, calendar-schedule,
>> calendar-availability, inbox-availability, calendar-proxy,
>> calendarserver-private-events
>> Content-Type: text/xml
>> Content-Length: 104
>> Server: Twisted/2.5.0 TwistedWeb/[twisted.web2, version 0.2.0]
>> TwistedCalDAV/1.3-dev (r2269)
>> <?xml version='1.0' encoding='UTF-8'?>
>> <error xmlns='DAV:'>
>>   <no-protected-ace-conflict/>
>> </error>
>> If so, I understand you suggestions but it seems overly complex.   
>> Is this
>> how it is handled on Leopard Server, thru OD and the GUi that comes  
>> with
>> that?
> Yes '<no-protected-ace-conflict/>' is what I was describing.
> NB There is another approach to this by using proxy. Here is how  
> this would work:
> 1) Instead of creating a group calendar, create a regular user to  
> represent the group.
> 2) Use that user's credentials to login and manage the calendars  
> (create/delete).
> 3) Assign other users as read-only or read-write proxies for that  
> user (the runshell proxies command easily manages that).
> A slight variation of this is to assign a group principal as a proxy  
> to a user. Then you can manage the proxies by adding individual  
> users to the group rather than directly using the proxy command.
> I think this is probably a better bet than managing the ACLs directly.
> There has been a fair amount of discussion in the Calendaring and  
> Scheduling Consortium by caldav-related folks about defining a more  
> generic proxy scheme than we have in our server. The primary goal of  
> this is to avoid admins, clients etc ever having to manipulate ACLs  
> directly, because, frankly, WebDAV ACLs are overly complex for most  
> of the operations people want to do. The goal would be to have the  
> server provision all the required types of ACLs and then use group  
> membership as a way of giving particular users the appropriate  
> rights. That is basically what the current proxy mechanism does.
> -- 
> Cyrus Daboo

More information about the calendarserver-users mailing list