EGroupware CalDAV and CardDav Sync, with NextCloud, as well as Thunderbird

StefanU 2022-10-23 14:44:09 UTC #3

Hi Zombie.

I cannot confirm that.
Works for me on: 102.2.2 on Linux Mint

Please give us information about your installation.
What are your preferences for CardDAV?

You can listen in on the communication:

Stefan

zombie 2022-10-23 15:07:31 UTC #4

My Distribution is OpenSuse Linux 15.3.
egroupware-docker-21.1.20220916-lp152.1.1.noarch This is my version of eGroupware. It’s from a Dockerized RPM.
I am using Mozilla Thunderbird to connect to eGroupware. My account has access rights.

zombie 2022-10-24 09:20:51 UTC #5

REPORT /egroupware/groupdav.php/masterz/calendar/ HTTP/1.1
Connection: Keep-Alive
Content-Length: 251
X-Forwarded-Server: olympia.pukey
X-Forwarded-Host: olympia.pukey
X-Forwarded-For: 192.168.0.4
X-Forwarded-Proto: https
Cache-Control: no-cache
Pragma: no-cache
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: empty
Authorization: Basic ***************
Depth: 1
Content-Type: text/xml; charset=utf-8
Accept-Charset: utf-8,*;q=0.1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Accept: text/xml
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0
Host: olympia.pukey
Content-Length: 251
Content-Type: text/xml; charset=utf-8

<?xml version="1.0" encoding="UTF-8"?>

https://olympia.pukey/egroupware/groupdav.php/masterz/calendar/16564396281
HTTP/1.1 207 Multi-Status
Date: Sun, 23 Oct 2022 23:29:00 GMT
Server: nginx/1.22.1
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Dav-Powered-By: EGroupware 21.1.001 CalDAV/CardDAV/GroupDAV server
X-WebDAV-Status: 207 Multi-Status
DAV: 1, 2, access-control, calendar-access, calendar-auto-schedule, calendar-proxy, calendarserver-principal-property-search, calendarserver-private-events, calendar-managed-attachments
Content-Type: text/xml; charset=“utf-8”

<?xml version="1.0" encoding="utf-8"?>

*** REPORT sync-collection /masterz/calendar/ --> “207 Multi-Status” took 0.005 s

*** 172.19.0.1 2022-10-23T23:29:00+00:00
REPORT /egroupware/groupdav.php/masterz/infolog/ HTTP/1.1
Connection: Keep-Alive
Content-Length: 253
X-Forwarded-Server: olympia.pukey
X-Forwarded-Host: olympia.pukey
X-Forwarded-For: 192.168.0.4
X-Forwarded-Proto: https
Cache-Control: no-cache
Pragma: no-cache
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: empty
Authorization: Basic ***************
Depth: 1
Content-Type: text/xml; charset=utf-8
Accept-Charset: utf-8,*;q=0.1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Accept: text/xml
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0
Host: olympia.pukey
Content-Length: 253
Content-Type: text/xml; charset=utf-8

<?xml version="1.0" encoding="UTF-8"?>

HTTP/1.1 207 Multi-Status
Date: Sun, 23 Oct 2022 23:29:00 GMT
Server: nginx/1.22.1
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Dav-Powered-By: EGroupware 21.1.001 CalDAV/CardDAV/GroupDAV server
X-WebDAV-Status: 207 Multi-Status
DAV: 1, 2, access-control, calendar-access, calendar-auto-schedule, calendar-proxy, calendarserver-principal-property-search, calendarserver-private-events, calendar-managed-attachments, addressbook
Content-Type: text/xml; charset=“utf-8”

<?xml version="1.0" encoding="utf-8"?>

<D:multistatus xmlns:D=“DAV:”>
</D:multistatus>
*** REPORT sync-collection /masterz/infolog/ --> “207 Multi-Status” took 0.003 s

*** 172.19.0.1 2022-10-23T23:59:00+00:00
REPORT /egroupware/groupdav.php/masterz/calendar/ HTTP/1.1
Connection: Keep-Alive
Content-Length: 251
X-Forwarded-Server: olympia.pukey
X-Forwarded-Host: olympia.pukey
X-Forwarded-For: 192.168.0.4
X-Forwarded-Proto: https
Cache-Control: no-cache
Pragma: no-cache
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: empty
Authorization: Basic ***************
Depth: 1
Content-Type: text/xml; charset=utf-8
Accept-Charset: utf-8,*;q=0.1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Accept: text/xml
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0
Host: olympia.pukey
Content-Length: 251
Content-Type: text/xml; charset=utf-8

<?xml version="1.0" encoding="UTF-8"?>

HTTP/1.1 207 Multi-Status
Date: Sun, 23 Oct 2022 23:59:00 GMT
Server: nginx/1.22.1
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Dav-Powered-By: EGroupware 21.1.001 CalDAV/CardDAV/GroupDAV server
X-WebDAV-Status: 207 Multi-Status
DAV: 1, 2, access-control, calendar-access, calendar-auto-schedule, calendar-proxy, calendarserver-principal-property-search, calendarserver-private-events, calendar-managed-attachments
Content-Type: text/xml; charset=“utf-8”

<?xml version="1.0" encoding="utf-8"?>

<D:multistatus xmlns:D=“DAV:”>
</D:multistatus>
*** REPORT sync-collection /masterz/calendar/ --> “207 Multi-Status” took 0.003 s

*** 172.19.0.1 2022-10-23T23:59:00+00:00
REPORT /egroupware/groupdav.php/masterz/infolog/ HTTP/1.1
Connection: Keep-Alive
Content-Length: 253
X-Forwarded-Server: olympia.pukey
X-Forwarded-Host: olympia.pukey
X-Forwarded-For: 192.168.0.4
X-Forwarded-Proto: https
Cache-Control: no-cache
Pragma: no-cache
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: empty
Authorization: Basic ***************
Origin: https://olympia.pukey
Depth: 1
Content-Type: text/xml; charset=utf-8
Accept-Charset: utf-8,*;q=0.1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Accept: text/xml
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0
Host: olympia.pukey
Content-Length: 253
Content-Type: text/xml; charset=utf-8

<?xml version="1.0" encoding="UTF-8"?>

collection>
HTTP/1.1 207 Multi-Status
Date: Sun, 23 Oct 2022 23:59:00 GMT
Server: nginx/1.22.1
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Dav-Powered-By: EGroupware 21.1.001 CalDAV/CardDAV/GroupDAV server
X-WebDAV-Status: 207 Multi-Status
DAV: 1, 2, access-control, calendar-access, calendar-auto-schedule, calendar-proxy, calendarserver-principal-property-search, calendarserver-private-events, calendar-managed-attachments, addressbook
Content-Type: text/xml; charset=“utf-8”

<?xml version="1.0" encoding="utf-8"?>

<D:multistatus xmlns:D=“DAV:”>
</D:multistatus>
*** REPORT sync-collection /masterz/infolog/ --> “207 Multi-Status” took 0.003 s

StefanU 2022-10-24 11:19:41 UTC #6

Hmmm…
I don’t see any access to the address book(?).

Which address have you configured in the TB?
Also test this address immediately in a private browser TB:

Stefan

zombie 2022-10-24 12:52:56 UTC #7

What address? I don’t know what address you are asking for.

StefanU 2022-10-24 16:14:50 UTC #8

Stefan

zombie 2022-10-25 00:51:44 UTC #9

Address Book Zombie Ryushu
https://olympia.pukey/egroupware/groupdav.php/masterz/addressbook/

There is a public facing address - this is the behind the NAT address. Private message me. if you are interested.

StefanU 2022-10-25 19:14:22 UTC #10

Please check this address in an webbrowser (Other browser or privat tab).
Do you get a user query and then the data from your address book?

We can also provide a test account at our data centre. Then you can test against it.
I think it’s more likely to be your installation than EGroupware or Thunderbird. But who knows…

Stefan

zombie 2022-10-26 14:32:18 UTC #11

I have had other tests with other users on my system, I’d like to ask: Are there characters such as \ that would break eGroupware’s addressbook parser? I am getting very inconsistent results, even with the vCard Parser?

zombie 2022-10-27 05:36:26 UTC #12

Okay, I figured a few things out: I created a Group Address book for a Linux Group, and it worked correctly. I believe my Personal address book has corruption in it.

StefanU 2022-10-27 06:06:17 UTC #13

Then gradually move the contacts to another address book and find the problematic address(es).

Stefan

zombie 2022-10-27 06:31:43 UTC #14

I dumped my entire Personal Address book into a VCF file, and reloaded it to my personal address book. It failed.

zombie 2022-10-27 07:28:30 UTC #15

I migrated the entire address book, and it imported successfully. However, there were slight formatting changes with regards to backslashes being escaped. So I purged everything, and tried again. Similar Result. Only now, there was an extra entry with just a comma in the table.

Could there be additional Rows I can’t see? eGroupaware is in a Docker instance. What I am asking is, could there be rows in the table that are not valid?

zombie 2022-10-29 06:32:06 UTC #16

So, I managed to get into the MariaDB instance in the Docker image and Truncate the address book, but now, ACLs are telling me my access to my own addressbook is forbidden.

RalfBecker 2022-10-29 06:53:03 UTC #17

I hope you did not really truncate egw_addressbook, as it also contains your user accounts!

If that’s the case, restore the table and only delete rows with contact_owner=<account_id-of-AB-you-want-to-delete>.

Anyway deleting/truncating a single table, is damaging DB consistency, as eg. contacts are not in a single table, so generally speaking you leave orphaned rows in other tables. Better mark the rows in EGroupware and let EGroupware delete them for your.

Ralf

zombie 2022-10-29 07:35:48 UTC #18

Thats exactly what happened, and I had to restore from backup, but my original problem is back.
My addressbook contains some malformed entries that Thunderbird and Akonadi have a hard time with (Akonadi will use up 100% of CPU Time and Consume all RAM.)

StefanU 2022-10-29 09:37:11 UTC #19

Why didn’t you do it that way? Then nothing would have been broken.

Stefan

zombie 2022-10-29 10:15:23 UTC #20

There are thousands, and if I just do a find and replace with sed, on a VCF export, I find 144 scattered back slashes, and commas in the entries.
However, I have found that if I delete a bunch of entries inthe Address book, the actual number of rows in the table stays the same, why is this? Is this the “Users are not allowed to purge contacts?”

StefanU 2022-10-29 10:40:13 UTC #21

Yes. Since

Stefan

zombie 2022-10-29 11:34:31 UTC #22

How do I purge already deleted entries from the table? I have a VCF File that I think has offending characters removed.