[dav] Server replies HTTP 403 instread of 401

[scriptum]

Description of problem

I'm trying to setup E-mail server with calendars. Samba for LDAP, Postfix for MTA, cyrus-imapd for IMAP and CalDAV services, cyrus-sasl for authentication. Everything is based on CentOS except cyrus-imapd because there was no CalDAV support in 2.4, i compiled it from fedora rpm (2.5.10).

While using Evolution as client, I cannot create any calendar events because it says that calendar is read-only. I tried both Evolution 3.12 and 3.20.

Listing of protocol debug: https://gist.github.com/scriptum/b4cda04f0ba78ffb571bc7b5a938aa09

Look at the end - server responses HTTP 403 headers, but content is "401 unauthorized".

Probably this response confusing Evolution client and makes it think that calendar is read-only.

[ksmurchison]

Try this patch:

evolution.diff.txt

[scriptum]

That didn't help unfortunately.

Upd:

• there is no proxy between Evo and Cyrus
• i used CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory to get logs
• i checked fedora patches, there is only one patch: http://pkgs.fedoraproject.org/cgit/rpms/cyrus-imapd.git/tree/fix-sched_param.patch
• I finally set up Cyrus 3.0.0-beta5 and it works well

[ksmurchison]

It doesn't look like the Fedora patch would break anything. Its simply resolving a name conflict.

[jasontibbitts]

That fedora patch (which is my doing) just brings the rename of that field that exists in 3.0 back to 2.5. Otherwise the code doesn't compile at all.

I dumped all of the other Fedora patches as part of the update to 2.5, but that's only in rawhide (our development stream) and I haven't even built it there yet. Heck, I haven't even tested it locally yet. But there really shouldn't be any differences between Fedora and upstream at this point, which has been my goal.

[scriptum]

@ksmurchison I tried without Fedora patch, same bug. Currently only 3.0.0 works.

[bosim]

@scriptum Seems pretty much like this one: http://www.heute-morgen.de/site/01%20Linux%20at%20Home/50_Getting_Cyrus_CalDAV_to_work_with_Evolution.shtml

[scriptum]

@bosim unfortunately this didn't work for CentOS 7.

[bosim]

I got it working with the following patch, since it is missing both PUT and DELETE. Seems evolution is not happy unless it has both.

diff --git a/imap/http_caldav.c b/imap/http_caldav.c
index 98c0f70..8cd8083 100644
--- a/imap/http_caldav.c
+++ b/imap/http_caldav.c
@@ -922,7 +922,7 @@ static int caldav_parse_path(const char *path,
        tgt->allow &= ~ALLOW_WRITECOL;
    }
    else if (tgt->flags != TGT_SCHED_INBOX) {
-       tgt->allow |= ALLOW_POST;
+       tgt->allow |= ALLOW_POST | ALLOW_WRITE | ALLOW_DELETE;

        if (strcmp(tgt->collection, SCHED_DEFAULT))
        tgt->allow |= ALLOW_DELETE;

[brong]

I've already investigated this. Evolution is wrong, they should check D:current-user-privilege-set if they want to know if a calendar is writable.  They already need to do a PROPFIND to see that the collection is a calendar, so hooking that check in is easy enough.

And I'm pretty sure patching this breaks other things, which is why I didn't do it last time I looked at this issue.

[ksmurchison]

This appears to be fixed in 3.0 where we assign ALLOW_WRITE and ALLOW_DELETE to any non-special calendar/addressbook collection. IMHO, Evolution is still wrong.

[dilyanpalauzov]

To my knowledge Evolution used the OPTIONS call to determine the access rights. But the result of the OPTION call ignored the authentication state. Since 2018 Evolution uses PROPFIND for this: https://bugzilla.gnome.org/show_bug.cgi?id=794874 .

Provided that the problem does not appear any more, can this case be closed?