Apple Calendar delegates see presence of read-protected calendars, get 403s trying to read them
Apple's Calendar application seems to handle and present delegated Principals helpfully and elegantly. But what if a Principal wishes one of his calendars to be completely private?
Unfortunately, even if the Davical web admin tool is used to clear all privileges for a given calendar, the delegate's Calendar client will still list that private calendar's name amongst those of the public ones.
It gets worse. As Apple Calendar knows the private calendar exists, it repeatedly attempts to discover its contents, resulting in infinite 403 warning dialogs each requiring explicit user dismissal. This makes the Calendar client impossible to use until the user manages to deselect the offending delegation between warning dialogs.
This may be similar to #110, where @stromnet found that between 1.1.2 and 1.1.5 403 errors began being logged for read-protected calendars. @karora responded that Apple may not be checking privileges when obtaining lists of Collections.
The behavior is also nearly identical to the issue described on Nabble by Adrien Malgoyre in July 2016. What is interesting here is that Adrien found the behavior appeared between the 1.1.1 and 1.1.3 releases and that, by reverting caldav-PROPFIND.php to 1.1.1 even with other files at 1.1.4, the problem went away. I tried this too, but caldav-PROPFIND.php 1.1.1 is incompatible with Davical 1.1.8.
I apologize that my experience is not in this kind of programming and I am sure I am missing mountains of details. Nevertheless the two other reports of similar behavior both indicate that Davical used to behave better in this respect...maybe a fix is possible? I've looked at the changes in caldav-PROPFIND.php between 1.1.1 and 1.1.3, but no luck.
(I tested with Davical 1.1.8 under Fedora 29, and Mac OS releases from El Capitan to High Sierra.)