André,
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.
TIA
Ian
> On May 11, 2017, at 5:10 PM, Andre LaBranche <d...@apple.com> wrote:
>
>
>> On May 11, 2017, at 7:46 AM, Ian Baker <iba...@eem.ca
>> <mailto:iba...@eem.ca>> wrote:
>>
>>> On May 10, 2017, at 8:27 PM, Andre LaBranche <d...@apple.com
>>> <mailto:d...@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 =
> calendar_object.calendar_resource_id
> WHERE calendar_object.resource_id = 26;
>
> Example:
>
> 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;
> url
>
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> "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 = (
> "E1CB3592-E7BD-41C4-A27C-6E23FEFFD197"
> )
>
> 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">
> <dict>
>
> <key>AdminPrincipals</key>
> <array>
>
> <string>/principals/__uids__/AEB68DD7-D2B8-4D4D-A574-2A4533DF36A4/</string>
> </array>
>
> </dict>
> </plist>
>
> 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/\\r//g
> :%s/^ //g
> :1,2d
> :$-2,$d
> :%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
>
> e.g.
>
> # psql -A -t -h /var/run/caldavd/PostgresSocket -U caldav caldav -c 'select
> icalendar_text from calendar_object limit 1;'
> BEGIN:VCALENDAR
> VERSION:2.0
> PRODID:-//Apple Inc.//Web Calendar Client//
> BEGIN:VEVENT
> UID:c6b8d8ac-c23b-23b1-ade0-2756d3ca8fee
> DTSTART;TZID=America/Los_Angeles:20150814T080000
> DURATION:PT1H30M
> DTSTAMP:20150813T182156Z
> SEQUENCE:2
> SUMMARY:New Event
> END:VEVENT
> BEGIN:X-CALENDARSERVER-PERUSER
> UID:c6b8d8ac-c23b-23b1-ade0-2756d3ca8fee
> X-CALENDARSERVER-PERUSER-UID:E1CB3592-E7BD-41C4-A27C-6E23FEFFD197
> BEGIN:X-CALENDARSERVER-PERINSTANCE
> TRANSP:OPAQUE
> END:X-CALENDARSERVER-PERINSTANCE
> END:X-CALENDARSERVER-PERUSER
> END:VCALENDAR
>
> (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)
>
> -dre
>
>
>>
>> What is particularly weird is that this event was also sent to another of
>> our users ‘Robert Cole’, and I can load his calendar in WebCal and view the
>> event without trouble. There were no errors on Rob’s javascript console in
>> Safari.
>>
>>
>> <PastedGraphic-1.png>
>>
>> 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:
>> VCALENDAR
>> X-CALENDARSERVER-PERUSER
>> X-CALENDARSERVER-PERINSTANCE
>> 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!
>>
>> TIA
>>
>> Ian
>> 450-465-1641
>>
>> <Robs Event.ics>
>>
>
_______________________________________________
calendarserver-users mailing list
calendarserver-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/calendarserver-users
