Page MenuHomePhorge

kolab-plugins calendar/taskutil caldav driver is not connecting to radicale
Open, NormalPublic

Description

Using a git release from around Jan 20th of kolab-plugins, connecting to radicale [AlmaLinux 9 setup, basically default], I keep getting forbidden when it tries to do a curl against /calendars.

  • I also have a cyrus imapd setup, which this seems to just work

libkolab/lib/kolab_dav_client.php

  • public function discover

I changed $roots to:

$roots = [
     'VEVENT' => '',
     'VTODO' => '',
     'VCARD' => '',
 ];

And I see now both my calendar, as well as the addressbook showing up in calendar and tasks.

  • above changed for testing, not a suggestion to fix [especially with addressbook being returned].

From that, I'd suspect the issue is that the way it is discovering the calendars is not compatible with the radicale expects.

I was comparing this to Thunderbird, which I 'think' does a propfind on / (vs /calendars) for current-user-privilege-set

  • Note: I am not familiar with the specifics of the CALDAV protocol.

Details

Ticket Type
Task

Event Timeline

Was probing this further, and noticed in listFolders the following responses:
(with discover modified to use $response = $this->request('/', 'PROPFIND', $body, ['Depth' => 1, 'Prefer' => 'return-minimal']); - removed $roots[$component])

<pre>
[07-Feb-2023 09:55:34 -0800]: <frv15vpc> @@@@@@@@<response>

<href>/dav%40ncoulson.com/personal_calendar.230126180111403/</href>
<propstat>
  <prop>
    <resourcetype>
      <C:calendar/>
      <collection/>
    </resourcetype>
    <displayname>personal</displayname>
    <CS:getctag>"033aa043db7f0e3e43a1483892a874ced466bc3b6ab07e46b78525318e5c58ba"</CS:getctag>
    <C:supported-calendar-component-set>
      <C:comp name="VEVENT"/>
      <C:comp name="VJOURNAL"/>
      <C:comp name="VTODO"/>
    </C:supported-calendar-component-set>
    <ICAL:calendar-color>#00ff00ff</ICAL:calendar-color>
  </prop>
  <status>HTTP/1.1 200 OK</status>
</propstat>
<propstat>
  <prop>
    <ns4:alarms/>
  </prop>
  <status>HTTP/1.1 404 Not Found</status>
</propstat>

</response>

[07-Feb-2023 09:55:34 -0800]: <frv15vpc> @@@@@@@@<response>

<href>/dav%40ncoulson.com/personal_addressbook.230126180111601/</href>
<propstat>
  <prop>
    <resourcetype>
      <CR:addressbook/>
      <collection/>
    </resourcetype>
    <displayname>personal</displayname>
    <CS:getctag>"138ff9409f442a3485308e6bbf862581ab3ec7004696d7301c517581bfb3a29a"</CS:getctag>
    <C:supported-calendar-component-set>
      <C:comp name="VTODO"/>
      <C:comp name="VEVENT"/>
      <C:comp name="VJOURNAL"/>
    </C:supported-calendar-component-set>
  </prop>
  <status>HTTP/1.1 200 OK</status>
</propstat>
<propstat>
  <prop>
    <ICAL:calendar-color/>
    <ns4:alarms/>
  </prop>
  <status>HTTP/1.1 404 Not Found</status>
</propstat>

</response>
</pre>

That the AddressBook is returning supported-calendar-component-set (with VTODO/VEVENT provided).

listFolders looks to be using the following check to grab just the folders it wants:

if (($component == 'VCARD' && in_array('addressbook', $folder['resource_type']))
    || in_array($component, (array) $folder['types'])
)

Which in the case of the above response, as types has values with the addressbook, it thinks it is a calendar.

(Probably a horrible hack, but did the following in listFolders for it to resturn what we need for radicale) - as well as the above change to not use /calendars in discovery
<pre>

if (($component == 'VCARD' && in_array('addressbook', $folder['resource_type']))
    || (!in_array('addressbook', $folder['resource_type']) && in_array($component, (array) $folder['types']))

</pre>

I really tested the drivers only with Cyrus/Kolab DAV servers, so it might indeed not work with others, but I don't fully understand where's the problem. Could you provide the full dav.log (with dav_debug=true in config) from the unmodified code?

Obviously returning supported-calendar-component-set on an addressbook folder does not make sense until this folder indeed supports both contacts and calendar objects. So, maybe not our fault?

machniak claimed this task.

Discovery bug fixed in 84ef4ac9e3c2. The other issue fixed in b7dc093954bdb6.

Tested this out against radicale, and now working as expected without the patch I mentioned in the ticket.

Thank you

conathan reopened this task as Open.EditedJul 8 2023, 2:54 AM

I tested against a cyrus imap service we had, and it was showing no calendars. (Working with radicale, failing on Cyrus)

I reintroduced the following (same disclaimer as above, probably wrong approach) to make it work:

diff -Naurp roundcubemail/plugins/libkolab/lib/kolab_dav_client.php roundcubemail.new/plugins/libkolab/lib/kolab_dav_client.php
--- roundcubemail/plugins/libkolab/lib/kolab_dav_client.php     2023-07-07 14:33:07.000000000 -0700
+++ roundcubemail.new/plugins/libkolab/lib/kolab_dav_client.php 2023-07-07 17:40:17.106260612 -0700
@@ -142,6 +142,14 @@ class kolab_dav_client

         // Note: Cyrus CardDAV service requires Depth:1 (CalDAV works without it)
         $response = $this->request('/', 'PROPFIND', $body, ['Depth' => 1, 'Prefer' => 'return-minimal']);
+        if (empty($response)) {
+          $roots = [
+            'VEVENT' => 'calendars',
+            'VTODO' => 'calendars',
+            'VCARD' => 'addressbooks',
+          ];
+          $response = $this->request('/' . $roots[$component], 'PROPFIND', $body, ['Depth' => 1, 'Prefer' => 'return-minimal']);
+        }

         if (empty($response)) {
             return false;

@conathan I hesitate to merge this patch. Without it it works for me with Cyrus v3 DAV service as well as with standard Kolab DAV service (e.g. at kolabnow.com).

machniak lowered the priority of this task from Needs Triage to Normal.Sep 27 2023, 12:24 PM

I would agree, probably not the right patch (Just provided it as it's what we do to make it work, just carrying the patch internally)

Speaking of, updated to 0333d78048c591aae9fbd3b8bca54c29cdbb33b5, Thu Apr 4 16:14:10 2024 +0200), and retested. Still needed to work with Cyrus on EL8.

Also noticed that $component was dropped in that function, so added a $component="VEVENT" to the above patch.