[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?

[rjbs]

:robot: I'm closing this issue by automation.

This issue refers only to a long-out-of-support version of Cyrus. We're trying to get a good handle on our open issues and pull requests, so that we can reliably use them as a backlog of things we hope to work on. If you are confident that this issue should be reconsidered, reopen it and explain why.

Remember, though, that there are only so many developers working on Cyrus, and we'd like to focus on the most important and/or low-hanging work.

Before you reopen this issue, please check that this issue is still present in the latest release of Cyrus, or the main development branch. An issue is considerably more likely to get resolved if you can provide a pull request which reproduces the issue in a Cassandane test.