Calendar Sharing - technical details on implementation
We are developing eM Client (https://emclient.com), a mail/calendar desktop client.
Recently, one of our resellers pointed out that cPanel has changed calendar delegation and it seems not to be working anymore in eM Client properly.
I would be glad if somebody from cPanel would get in touch with me so I can share our findings, logs and discuss possible options to make this feature work with our client, which tries to adhere to RFCs and specifications as much as possible.
-
Hey there! Details about the change to the calendar system can be found here:
https://docs.cpanel.net/knowledge-base/webmail/cpdavd-service-replaces-ccs-plugin/
Let me know if you need more specifics than that and I'll be happy to help as much as I can!
0 -
Hello there! We are having trouble with shared calendars over CalDAV, which seem not to adhere to WebDAV specification - mainly, the name/URI of the shared calendar is not under the main calendar root.
As an example without giving out account details:
PROPFIND on https://ourdomain:2080/calendars/test1@ourdomain/
Returns several calendars.
The main one being with href /calendars/test1@ourdomain/calendar/
and a shared one with href /calendars/test2@ourdomain/calendar/
Which violates the standard, becuase all URIs should fall under root of principal, which is test1@ourdomain , and such path is not in shared calendar.
Also, according to draft-pot-webdav-resource-sharing-04 RFC, which describes the calendar sharing, the server shall maintain link under the main user towards the shared calendar, and not link the shared calendar directly.
SabreDAV, as an example of calendar server which supports calendar sharing, assigns random ID to the shared calendar which works without issues with eM Client
I wonder if you could look into this and update cpdavd to follow WebDAV specification on URI names.0 -
Howdy,
I'm a developer on the team which wrote the CALDAV/CARDDAV extensions to cpdavd. Thanks first off for coming to us with this, as our primary concern with this is client compatibility for the subset of features we decided to implement from the CAL/CARDDAV standards. As far as our testing on major clients, this URL not being under the principal's root did not cause issues with calendar sharing. When we had read through the relevant RFCs, we did not see any requirement for the share-resource-uri to specifically maintain that kind of link, though I won't claim that we haven't somehow misinterpreted things there or missed something.
Do you happen to know what section specifically mentions this in the RFC you cited? I'm currently having some trouble finding what you were talking about. Otherwise, I'm happy to hear you are testing versus our code, and I'll talk to the team to see just what kind of code change we'd need to make here to help your client work properly with cpdavd. Would it suffice for the URL to look something like /calendars/test1@ourdomain/test2@ourdomain-calendar, or would it be better to specifically use a UUID here like you suggest?
0 -
Hello Andy,
Thank you very much for the reply and explanation.
Hereby are details from RFCs:
RFC 4918 (WebDAV), section 5.2. Collection Resources states how collections and path segments interact
Based on the RFC 4791 (CalDAV), section 4.2 Calendar Collection mentions restrictions on calendar collections in partThe following restrictions are applied to the resources within a calendar collection:
Where in point a, it is explicitly stated that
Calendar collections MUST only contain calendar object resources and collections that are not calendar collections
Thus having in a calendar collection in a calendar collection is not allowed, thus the path /calendars/test1@ourdomain/test2@ourdomain/calendar
would violate CalDAV RFC.draft-pot-webdav-resource-sharing-04 (https://datatracker.ietf.org/doc/html/draft-pot-webdav-resource-sharing-04) states:
If the sharee chooses to accept, then a new resource is created at a location that's accessible to the sharee.
---
To sum up, the preferred and most universal solution according to RFCs is to have the path in format /calendars/test1@ourdomain/UUID for shared calendars.
In this case, the calendars will show side by side in eM Client automagically like in the attached screenshot (I faked the response via fiddler just to provide visual, manually clearing the domain):If you agree to the above UUID path format and a test account is provided for us, I could try the change almost immediately on any test/development server to confirm and/or check if the implemented change is working with us correctly before rolling it out.
Thank you very much for the help.
0 -
We certainly can arrange a development license for you to test this if the 30 day trial license is insufficient for testing when the time comes for that.
Meanwhile I do have a few extra questions:
* Does the trial license for your product grant access to the calendar view for us to test this on our end? That'd probably be important to verifying the fix on our end.
* How specifically does /calendars/test2@ourdomain/calendar (the shared one) become a "collection within a collection" and thus violate RFC? Far as I can tell, that's just a link outside of your principal (which if shared, isn't really a problem to make work code-wise on our end... which is why we did that). I'm mostly curious about the original point of contention -- "all URIs should fall under root of principal." Interestingly, in our testing, none of the biggest clients (thunderbird, mac client, etc.) cared about this (which is somewhat surprising, as you'd at least think the Mac client would insist on this if it were a "hard" requirement given how Apple's calendarserver indeed used UUIDs for this).
For now I've filed an internal case (HB-7708) to follow up on this.
0 -
We do not have a trial license for cPanel - we were created a test account by one of our reseller who coincidentally also sells cPanel, in response to support ticket he opened with us as having issues with calendar and delegation.
First, there was an issue with defined timezones we use which prevented users to create events at all in calendar. This got solved in the meantime, probably by other ticket. We are not working on the delegation.
Our license allows for 30 days of unlimited use for every account type. If that would not suffice, we would be able to create a not-for-resale license for you.
The calendars/test2@outdomain/calendar (shared one) violates basic WebDAV URLs - My first comment within RFC 4791.
The comment about having a collection within collection (your suggestion of /calendars/test1@ourdomain/test2@ourdomain/calendar) would break collections within collection, as there would is also /calendars/test1@ourdomain/calendar collection (the primary calendar)
0 -
Hmm, so probably either
A collection's state consists of at least a set of mappings between path segments and resources, and a set of properties on the collection itself. In this document, a resource B will be said to be contained in the collection resource A if there is a path segment mapping that maps to B and that is contained in A. A collection MUST contain at most one mapping for a given path segment, i.e., it is illegal to have the same path segment mapped to more than one resource.
Which presumably means that "resource" in our context would have to map directly to "principal." This would suggest to me that the user should be a unique identifier on the server, not necessarily the collection name itself. In our context, the principal name is in fact unique, which is why we decided not to go with a UUID for that component.
Perhaps instead:
... In cases where a server treats a set of segments as equivalent, the server MUST expose only one preferred segment per mapping, consistently chosen, in PROPFIND responses.
This seems to suggest that we should be consistent at all times about the path components to a collection. In this case it would suggest that the optimal implementation is to do the following for all resources RE paths, be they collections or otherwise:
/$UUID
Then keep track of the mapping internally on the server (as collection types and "principal" are just as easy to map to a UUID). The client doesn't really need to care about anything being human-readable at all, just that there's only ever one path component to any given resource at all, ever. This of course, is probably not very *human* friendly, so I understand why very few server packages have chosen this model, instead opting for static path components for principal information, calendar and addressbook collections, only resorting later to a UUID, whether that be in naming the individual ICS/VCF files or the collections themselves (Apple's calendarserver, notably had *aliases* for the "human readable" components and in fact did this under the hood).
Realistically, the conflict here isn't that it's `test2@whatever.domain` being the principal, more that it's that the name of the collection is `calendar` for both of them if I'm reading it right. Using a UUID could solve this either by having it be the whole name or a suffix/prefix. In fact for adding anything other than the "default" calendar, we do append a UUID to the name so that you can name multiple collections the same thing (basically) and it just appends the UUID to the name in that case, which solves your case. That said, in this case, it's not like we're considering this path component as equivalent under the hood (as the principal component preceding it implies it won't be equivalent), so I'd still disagree it applies, but I at least now understand the argument.
For now users could work around this by just renaming the calendar in a terminal to contain a generated UUID (example here uses a user named "cptest"):
/usr/local/cpanel/3rdparty/bin/perl -MCpanel::UUID -e 'print Cpanel::UUID::random_uuid(), "\n";'
01409e63-7789-48e4-b870-0bea3e3095d1
mv /home/cptest/.caldav/cptest/calendar /home/cptest/.caldav/cptest/calendar-01409e63-7789-48e4-b870-0bea3e3095d1
sed -i 's/^\[calendar\]$/[calendar-01409e63-7789-48e4-b870-0bea3e3095d1]/' /home/cptest/.caldav/cptest/.metadataThen your calendar now has a UUID tacked on to it. All the data's handled in the filesystem, so overall it's pretty simple to deal with.
Anyways, I'm sure we can do something about it now, even if it seems somewhat silly to do so (just use the URL it gave you and it isn't a problem). Calendar does not equal calendar in the context of different principals, just as $UUID under another principal would in fact be another calendar even if it had the exact same UUID, as it's just a path on the filesystem). Perhaps these UUIDs don't have to be unique to solve your problem, just merely unique given the path components preceding them (which also should be "illegal" if no path component may be repeated, ever). In either case there would never be any *real* opportunity for naming collision, and in the second case even less so due to the previous path component.
I'll try both approaches soon to find out whether I'll need "actual" server-wide uniqueness per path component for compatibility with your client, or whether it only cares in the context of the previous path component. Thanks!
1 -
Hello
There are no new developments.
There are quite a few EMClient customers who have had their calendars working since your CalDav implementation.
Any ETA on this?
0 -
Hello Andy Baugh
Is there any version available which I could try, or do you have any expectation for the change? Thank you very much0 -
I wish I could have better news for you on this, but as of yet I have not gotten approval to even work on this myself. We have had an immense backlog of work for various things getting in the way sadly. I will of course keep an eye on this case and update this thread once I see action from others on this or if I get the green light to fix it myself.
1
Please sign in to leave a comment.
Comments
10 comments