Great! 👍
*From:* Ken Murchison
*Sent:* Wednesday, June 06, 2018 16:22
*To:* Cyrus Devel
*Subject:* Re: shared xDAV resources
I looked into shared calendar discovery and I have 2 ideas in mind. One
is simpler than the other, and I have an email into one of the Apple
client devs to see which of the two (or both) they may support. He's
currently at CalConnect in Tokyo and I'm hoping it prompts some
discussion among the membership.
On 05/26/2018 07:19 PM, Anatoli wrote:
Hi Ken,
Thanks for dedicating time to this issue.
The *current problem*: the auto-discovery mechanism for CalDAV/CardDAV
resources in Cyrus doesn't return the /shared/ resources a user has
access to. It does return all resources in the /user folder/
(/dav/calendars/user/<user@domain>/) for all known clients (including
iOS).
The clients that I'm aware of that /only/ support auto-discovery
mechanism (i.e. where users can't specify a direct resource URL), is
all iOS (Calendar and Contacts apps), not sure about the same Mac
apps. Then there is a lot of clients that support both methods (e.g.
Evolution, even Thunderbird has a plug-in that enables auto-discovery)
and its much simpler to auto-discover everything just entering the
server address and user/pass than configuring the same for each
resource one by one.
For me the most basic functionality would be enough at this time: the
clients that support auto-discovery mechanism should be able to list
and access the shared resources the same way they access now the
resources in the user folder. Once this works, we could deploy shared
calendars and addressbooks in production, gather users feedback and
see what could be improved.
*TL;DR*: I guess it would be enough to just include the shared
resource URLs in the list returned by Cyrus to PROPFIND
/dav/principals/user/<user@domain>/ query.
With respect to *ACLs*, they do work correctly on all resources
(shared and user-owned). Here probably one thing could be improved to
not confuse users. Now if a user tries to introduce changes to a
calendar/addressbook where he has a read-only access (rl ACL), his
client gets 403 Forbidden and it asks the user to enter different
credentials. The ideal would be to return some other code that won't
trigger a credentials request in the client (maybe something like
"operation not supported" or some temporary error). The idea is to
activate this behavior only when the user is properly authenticated
and has a r/o access, but asks for a write operation, i.e. it's not
for all 403 Forbidden cases:
if (user.authenticated && user.acl(requested_resource) == r&l &&
requested_operation == w|i|p|k|x|t|e)
return "operation not supported"
else
return "403 Forbidden"
With respect to the *scheduling* support, I can't talk for the entire
community, but at least in my case, we don't use this feature at the
moment not even for user calendars. Our shared calendars use cases now
are to create reminders for public holidays, employees birthdays, etc.
and for meeting rooms reservations. Once the users become familiar
with shared calendars, new use cases would appear probably.
One feature that would be nice to have (but it's workaround-able now
with custom scripts, so it's of low priority) is to be able to create
shared calendars and addressbooks with a web GUI the same way user
calendars and addressbooks could be created now.
With this functionality we would probably have to define the concept
of shared resources /scope/, i.e. global (public) shared resources and
user-owned shared resources, with the main difference being their path
(/dav/calendars/X vs /dav/calendars/user/<user@domain>/X) and a
special permission (probably w, i or k on /dav/calendars/ could work)
that would allow the user to create global (public) shared resources.
Also, the current web GUI for user calendars/contacts could have an
option to add permissions on available resources for other users (e.g.
a mail address field and 2 radio buttons for access type
(read|write)), so its owner could share his/her calendars/contacts
directly from the existing GUI.
Please let me know if I can provide additional details.
Thanks,
Anatoli
*From:* Ken Murchison
*Sent:* Friday, May 25, 2018 10:29
*To:* Cyrus Devel
*Subject:* Re: shared xDAV resources
Hi Anatoli,
I'm guessing that this will be a couple of days work. Bron has told
me to carve out some time to work on this. I have 4 flights and 2
hotel stays coming up June 4-14, which will give me some time to look
at this.
Can you summarize the functionality that you require and what the
current problems are? E.g., Do you need scheduling support on the
shared calendar? Do Apple clients not autodiscover the calendars?
Are ACLs working properly?
On 05/25/2018 12:22 AM, Anatoli wrote:
Bron, Ken,
I've just created a new issue for this:
https://github.com/cyrusimap/cyrus-imapd/issues/2373, so it's not
lost in the mails archive.
Please let us know if the community can sponsor the development.
Thanks,
Anatoli
*From:* Anatoli
*Sent:* Monday, April 09, 2018 00:40
*To:* Cyrus Devel
*Subject:* Re: shared xDAV resources
Bron, Ken,
Thanks for your explanations.
Do you consider this is something possible to implement for an
outside developer, i.e. without Cyrus HTTP/DB implementation
internals understanding, nor solid knowledge of xDAV RFCs? I'd like
to collaborate, but I believe it only makes sense to start this work
if I could finish it without too much effort to become fluent with
the related internals/standards.
On the other hand, if I don't have a reasonable chance to implement
it myself, could I sponsor the development by your team or help your
team in other ways (e.g. extensive testing, logs/telemetry, etc.)?
I have the Cyrus xDAV functionality deployed experimentally at one
organization, everything looks good so far, but the fact that shared
resources (calendars and addressbooks) can't be accessed from iOS
devices obstructs its definitive deployment there and at other
organizations. WebDAV resources work well on all devices with some
minor issues on macOS (I'm debugging them now, looks like they only
occur on previous versions of macOS, i.e. El Capitan).
> I originally wrote the code to handle public calendars in the
"shared" namespace, but I focused on user calendars first, and public
calendar support got tossed on the back burner. It appears that the
code for public calendars partly works.
Public calendars actually work quite well, if the device can discover
them. Currently, I've tested them with Thunderbird and haven't found
any issues.
Remote addressbooks are not supported in Thunderbird, so I use
/CardBook/ add-on and it works well with shared addressbooks, no
issues detected. /Evolution/ supports CardDAV natively and also works
well with shared addressbooks.
Regards,
Anatoli
*From:* Ken Murchison
*Sent:* Saturday, April 07, 2018 21:53
*To:* Bron Gondwana, Cyrus Devel
*Cc:* Ken Murchison
*Subject:* Re: shared xDAV resources
I originally wrote the code to handle public calendars in the
"shared" namespace, but I focused on user calendars first, and public
calendar support got tossed on the back burner. It appears that the
code for public calendars partly works.
My first thought to get auto-discovery of public calendars is to add
/dav/calendars as a second calendar-home-set for users and see what
the Apple clients do with that. I don't know if they can handle
multiple home-sets. If that doesn't work, then we could map public
calendars into the user's home-set via the same subscription
mechanism that we use for CalDAV sharing.
To answer the original question, calendars are enumerated by
meth_propfind() and propfind_by_collection() in http_dav.c
On 4/7/18 8:25 PM, Bron Gondwana wrote:
Ken knows this code best. I bet there's something which is
requiring that there's a user on the mboxname because we implement
the same behaviour at FastMail by having a separate user on which
shared resources are kept. The DAV resources are stored per-user,
and without a place to keep them for "shared calendars" that code
might just not be accessible. I'm sure it would be possible to
create a shared DAV database as well for this case, but it just
needs some programming effort.
Bron.
On Sun, 8 Apr 2018, at 07:30, Anatoli wrote:
Hi All,
I'm trying to understand the code responsible for enumerating user
calendars (and xDAV resources in general) to try to make the
discovery work for shared resources too (currently there's no way
to access shared resources with Apple xDAV client implementation,
yes with Thunderbird as it doesn't use the discovery mechanism, but
instead should be pointed to the exact URL for each calendar). If I
understand it correctly, the functionality is in imap/http_caldav.c.
Could you please point me to the place where the enumeration occurs
and briefly mention how the general workflow looks like?
The client asks for:
PROPFIND /dav/calendars/user/<user@domain>/
<A:propfind xmlns:A="DAV:">
...
The server responds with:
HTTP/1.1 207 Multi-Status
<A:multistatus xmlns:A="DAV:" ...>
<A:response>
<A:href>/dav/calendars/user/<user@domain>/</A:href>
<A:propstat>
...
</A:response>
<A:response>
<A:href>/dav/calendars/user/<user@domain>/Default/</A:href>
<A:propstat>
<A:prop>
...
The idea is to include in the returned lists the shared calendars
too with the discovery logic based on the IMAP shared folders.
Below goes the initial exchange between the calendar app on iOS
10.2.6 and Cyrus 3.0.5 when the exact URL (/dav/calendars/shared/)
for the shared calendar is provided in the advanced settings of the
app (the URL finally resets to the user principals folder
(/dav/principals/user/t...@domain.com/) as iOS is pointed to it by
Cyrus). In the attached file goes the telemetry for the rest of the
communication.
Thanks,
Anatoli
---------- t...@domain.com <mailto:t...@domain.com> Sun Mar 25 06:05:36
2018
<1521968736<*PROPFIND* */dav/calendars/shared/* HTTP/1.1
Accept: */*
Content-type: text/xml
Connection: keep-alive
Content-length: 181
Host: mail.domain.com
User-agent: iOS/11.2.6 (15D100) accountsd/1.0
Prefer: return=minimal
Depth: 0
Brief: t
Accept-language: en-us
Authorization: Basic ...
Accept-encoding: br, gzip, deflate
<1521968736<<?xml version="1.0" encoding="UTF-8"?>
<A:propfind xmlns:A="DAV:">
<A:prop>
<A:current-user-principal/>
<A:principal-URL/>
<A:resourcetype/>
</A:prop>
</A:propfind>
>1521968736>HTTP/1.1 207 Multi-Status
Date: Sun, 25 Mar 2018 09:05:36 GMT
Strict-Transport-Security: max-age=600
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal
Content-Type: application/xml; charset=utf-8
Content-Length: 546
<?xml version="1.0" encoding="utf-8"?>
<A:multistatus xmlns:A="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<A:response>
<A:href>*/dav/calendars/shared/*</A:href>
<A:propstat>
<A:prop>
<A:current-user-principal>
<A:href>*/dav/principals/user/t...@domain.com/*</A:href>
</A:current-user-principal>
<A:resourcetype>
<A:collection/>
<C:calendar/>
</A:resourcetype>
</A:prop>
<A:status>HTTP/1.1 200 OK</A:status>
</A:propstat>
</A:response>
</A:multistatus>
<1521968736<OPTIONS /dav/principals/user/t3%40domain.com/ HTTP/1.1
Host: mail.domain.com
Connection: keep-alive
Accept: */*
User-Agent: iOS/11.2.6 (15D100) accountsd/1.0
Accept-Language: en-us
Content-Length: 0
Accept-Encoding: br, gzip, deflate
>1521968736>HTTP/1.1 200 OK
Date: Sun, 25 Mar 2018 09:05:36 GMT
Strict-Transport-Security: max-age=600
Cache-Control: no-cache
Link: </dav/principals/.server-info>; rel="server-info";
token="80769c2c66d340ecd178710db26d56b9c4699e3e"
DAV: 1, 2, 3, access-control, extended-mkcol, resource-sharing
DAV: calendar-access, calendar-auto-schedule
DAV: calendar-query-extended, calendar-availability,
calendar-managed-attachments
DAV: calendarserver-sharing, inbox-availability
DAV: addressbook
Allow: OPTIONS, GET, HEAD
Allow: PROPFIND, REPORT, COPY
Content-Length: 0
Email had 1 attachment:
*
|telemetry.log|
36k (text/x-log)
--
Bron Gondwana, CEO, FastMail Pty Ltd
br...@fastmailteam.com
--
Kenneth Murchison
Cyrus Development Team
FastMail Pty Ltd
--
Ken Murchison
Cyrus Development Team
FastMail US LLC
--
Ken Murchison
Cyrus Development Team
FastMail US LLC