[CalendarServer-users] Client library and admin tool

Scott Buchanan dscottbuch at mac.com
Fri Apr 4 08:19:03 PDT 2008


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- 
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:'>

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?
On Apr 4, 2008, at 7:58 AM, Cyrus Daboo wrote:

> Hi Scott,
> --On April 4, 2008 7:22:09 AM -0700 Scott Buchanan  
> <dscottbuch at mac.com> wrote:
>> Any idea why the ACL doesn't change and why the error (Ignoring  
>> error)?
>> Also, is there any way with runshell.py to increase the reporting?
> The logging command in the shell will turn on protocol tracing  
> (basically it will print every http request/response.)
> I think what is happening in your case is that you are running into  
> a restriction on what you can change in an ACL. By default the  
> server provisions each user and group to have DAV:all inheritable  
> access to their on calendar home, and that DAV:ace element is  
> protected. As a result, you cannot add a DAV:ace that possibly  
> conflicts with that by overriding a privilege.
> I think what you need to do is something like this:
> 1) Create a group (enabled for calendaring) for the calendar data  
> and make those users who should be able to create/delete calendars  
> members of that group.
> 2) Create another group (not enabled for calendaring) and add users  
> who should have read/write access to the event data, but not create/ 
> delete calendar rights.
> 3) For each calendar created in the main group, change the ACL on  
> the calendar collection to give the non-calendar group DAV:read and  
> DAV:write access only.
> Ultimately it would probably be handy if you could set the read/ 
> write access for the non-calendar group on the calendar home and  
> have that be inheritable so that you don't have to set it up on each  
> new calendar. Whilst our server does support an option to make a  
> DAV:ace inheritable, there is no way to control that via the ACL  
> method.
> -- 
> Cyrus Daboo

More information about the calendarserver-users mailing list