[CalendarServer-users] Questions regarding delegation, attachments and time errors
ibaker at eem.ca
Sat May 13 14:19:29 PDT 2017
I can confirm that the problematic event doesn’t seem to crash the boss’s Calendar.app. It just doesn’t show up in his calendar, nor does the associated event wit the same UID. He is running 10.11.6, and I accessed his calendar to confirm, and I’m running 10.12.5. Again, no crash. To avoid the erroneous notifications mentioned earlier, I used the macOS Guest account with no mail accounts configured.
I was able to get the event's resource_id, and then establish its URL. I even validated that the URL was correct by getting it using Safari and comparing the result with the expected event. I authenticated in Safari with both the boss’s userid/password as well as the Bonus round #1 AdminPrincipal's userid/password, so both authentications were working correctly.
However, I am truly hesitant to report that when attempting the curl -X delete, and authenticating either way, I get this:
<html><head><title>Unauthorized</title></head><body><h1>Unauthorized</h1><p>You are not authorized to access this resource.</p></body></html>
Not sure where to go from here.
> On May 11, 2017, at 5:10 PM, Andre LaBranche <dre at apple.com> wrote:
>> On May 11, 2017, at 7:46 AM, Ian Baker <ibaker at eem.ca <mailto:ibaker at eem.ca>> wrote:
>>> On May 10, 2017, at 8:27 PM, Andre LaBranche <dre at apple.com <mailto:dre at apple.com>> wrote:
>>> Yeah, wow. There are actually two distinct VCALENDAR objects here - both with the same UID. I've never seen this happen.
> I was embarrassingly mistaken in my characterization of this. The psql output clearly indicates there are two rows, and it is not abnormal to have multiple calendar_object rows for events with the same UID; the organizer and attendees all get their own copy.
> Both of the events, when placed into discrete ics files, validate successfully.
> Anyhow, even though the pycalendar validator is OK with both of these events, the one that has no organizer / attendee information but does have a RECURRENCE-ID crashes Calendar.app if I try to import it. That's bad, and I sent a bug to Calendar to remedy that.
> It's unclear why this event is in the state that it's in, but it's not a good state. The easiest option for unblocking the web calendar is probably to just delete the problem event. Since it's just a (seemingly broken) cancel, there should be no harm in this. Never make changes to calendar data using direct database access; stick with HTTP to keep everything coherent. An HTTP "delete" request should work fine, the only tricky part is finding the URL to delete, since the event in question is likely returned in a batch request, in which case the individual URLs won't appear in the access.log.
> The first step is to find the resource_id of the event, which is another column on calendar_object. We'll use the event UID and a substring search for RECURRENCE-ID as the predicates. In the example below, use your event's UID instead (which is 040000008200E00074C5B7101A82E008000000004020622BEB7AD201000000000000000010000000C05F922AF30E4145839AF52B293ABFFB)
> caldav=# select resource_id, calendar_resource_id from calendar_object where icalendar_text LIKE '%RECURRENCE-ID%' and icalendar_uid = '8F98441F-3890-457E-B0E6-6875EE527951';
> resource_id | calendar_resource_id
> 26 | 2
> (1 row)
> (calendar_resource_id is a reference to the calendar that contains the event. There shouldn't be multiple results for this query in your case, but if there are, this value would probably vary).
> With the resource_id in hand, you can compose a URL by traversing the CalendarServer resource hierarchy using something like the following, substituting your resource_id on the last line of the query, and changing 'example.com <http://example.com/>' to something correct.
> SELECT '"https://example.com:8443/calendars/__uids__/' <https://example.com:8443/calendars/__uids__/'>
> || owner_uid
> || '/'
> || calendar_resource_name
> || '/'
> || resource_name
> || '"' as URL
> FROM calendar_bind
> JOIN calendar_home
> ON calendar_bind.calendar_home_resource_id = calendar_home.resource_id
> JOIN calendar_object
> ON calendar_bind.calendar_resource_id =
> WHERE calendar_object.resource_id = 26;
> caldav=# SELECT '"https://example.com:8443/calendars/__uids__/' <https://example.com:8443/calendars/__uids__/'>
> caldav-# || owner_uid
> caldav-# || '/'
> caldav-# || calendar_resource_name
> caldav-# || '/'
> caldav-# || resource_name
> caldav-# || '"' as URL
> caldav-# FROM calendar_bind
> caldav-# JOIN calendar_home
> caldav-# ON calendar_bind.calendar_home_resource_id = calendar_home.resource_id
> caldav-# JOIN calendar_object
> caldav-# ON calendar_bind.calendar_resource_id =
> caldav-# calendar_object.calendar_resource_id
> caldav-# WHERE calendar_object.resource_id = 26;
> "https://example.com:8443/calendars/__uids__/E1CB3592-E7BD-41C4-A27C-6E23FEFFD197/calendar/8F98441F-3890-457E-B0E6-6875EE527951.ics <https://example.com:8443/calendars/__uids__/E1CB3592-E7BD-41C4-A27C-6E23FEFFD197/calendar/8F98441F-3890-457E-B0E6-6875EE527951.ics>"
> (1 row)
> Now with an URL, you can fire a DELETE using curl. Such a request usually needs to be authenticated with the credentials of the user whose GUID is shown after the __uids__ portion of the URL (in the DB, this is calendar_home.owner_uid). To confirm that username:
> % dscl /Search search /Users GeneratedUID E1CB3592-E7BD-41C4-A27C-6E23FEFFD197
> andre GeneratedUID = (
> Now you can run curl, supplying the password when prompted:
> curl -u <username> -X DELETE <url>
> With this seemingly invalid event out of the way, the web calendar should now load (or at least, get stuck on something else).
> Bonus round #1
> ... but you might want to do this on behalf of your boss, without knowing his password. To do that, add yourself as an AdminPrincipal using the following CalendarServer config in the file:
> "/Library/Server/Calendar and Contacts/Config/caldavd-user.plist" (this file doesn't exist by default, and is read after caldavd-system.plist, overriding anything defined there)
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd <http://www.apple.com/DTDs/PropertyList-1.0.dtd>">
> <plist version="1.0">
> Specify your own GUID instead of the one shown above, which you can find with a dscl query using your username, e.g.:
> $ dscl /Search read /Users/andre GeneratedUID
> GeneratedUID: E1CB3592-E7BD-41C4-A27C-6E23FEFFD197
> Finally, restart CalendarServer to activate the new config:
> sudo calendarserver_config --restart
> After doing the delete, to disable the AdminPrincipal config, either rename the caldavd-user.plist file, or comment out the array elements like this:
> <!-- <string>/principals/__uids__/AEB68DD7-D2B8-4D4D-A574-2A4533DF36A4/</string> -->
> ... then bounce the service.
> Bonus round #2
> Also I confirmed that the validation steps included in my prior email work as written; the second 'cd' is not optional, and I was trying to do that as an alternative to 'installing' the module. But now that I remember that virtualenv <https://virtualenv.pypa.io/en/stable/> exists, here's a more standard approach:
> # provision a new virtualenv, use it, install pycalendar from git using pip
> virtualenv pycalendar-env
> cd pycalendar-env
> source bin/activate
> pip install git+https://github.com/apple/ccs-pycalendar.git@master <git+https://github.com/apple/ccs-pycalendar.git@master>
> # verify - this should print the path to the pycalendar module that was just installed
> python -c 'import pycalendar ; print pycalendar.__path__'
> # run the validator
> % python -m pycalendar.validator ~/1.ics
> No problems
> Bonus round #3
> The icalendar_text returned previously by psql isn't in proper iCalendar form. Even though there are psql options for raw output, I would have to look those up, while the following vim commands flow like water onto my keyboard:
> :%s/^ //g
> :%s/[ ]*$//g
> ... ok I looked it up, and it's easier than the above: just start psql like this: sudo psql -A -t -h /var/run/caldavd/PostgresSocket -U caldav caldav
> # psql -A -t -h /var/run/caldavd/PostgresSocket -U caldav caldav -c 'select icalendar_text from calendar_object limit 1;'
> PRODID:-//Apple Inc.//Web Calendar Client//
> SUMMARY:New Event
> (and finally, the X-CALENDARSERVER-PERINSTANCE component would not be exposed to clients; this component is internal to CalendarServer and is stripped from event bodies as they leave the server)
>> I exported Rob's calendar and found one of the 2 events. The ‘cancelled" event was not in Rob’s calendar that I could find. I’ve attached Rob's event as an .ics file. From what I could see Rob’s version didn’t have lines related to the following properties:
>> and there seemed to be minor parsing differences (quotes around certain fields e.g. email addresses).
>> If these are not the source of the error on the boss’s ('Paul MacLean’) WebCal display, might it be something else that is causing the error? The event just before or the event just after this one? Or perhaps the volume of events in the boss’s calendar - he never throws anything away!
>> <Robs Event.ics>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the calendarserver-users