Terminbestätigung aus Thunderbird Lightning

schwendtke 2019-11-12 09:18:05 UTC #1

Hallo zusammen,

erstmal was zur Umgebung: Thunderbird 60.8.0 und Groupware 17.1 ( calendar 17.1.003 / groupdav 17.1 / Debian9.11).

Folgende Problematik: Beim Erstellen eines Termins mit mehreren Teilnehmern können alle Nutzer diesen Termin mit der Groupware aus dem Browser heraus bestätigen/ablehnen etc.

Eine Terminbestätigung via Handy (Android, CalDav-Sync) funktioniert ebenfalls.

Im Thunderbird/Lightning Kalender führt eine “Teilnahmeaktion” zu einer Fehlermeldung.

Im TB:
grafik

Im error.log des Apache:
[client 192.168.2.100:62353] X-WebDAV-Status: 403 Forbidden
[client 192.168.2.100:62353] ### PUT /calendar/6849.ics --> “403 Forbidden” took 0.006 s

Nach meinem Verständnis ist es also kein Problem von Rechten, welche der Eingeladene eventuell besitzen muss, sondern vielleicht ein Problem der Authentifizierung durch den Thunderbird? 403 sagt ja recht eindeutig aus, dass da in Sachen Zugriff was nicht stimmt.

Status-Code: 2147500037 deutet darauf hin, so fand ich einiges beim Suchen im Netz, dass es bei Berechtigungen für caldav / groupdav Probleme geben könnte bzw. Einstellungen zu tätigen sind.
Kann das jemand nachvollziehen? Kann jemand helfen? Ich sag schon mal Danke!

Terminbestätigung aus Thunderbird Lightning nicht möglich

StefanU 2019-11-12 09:42:28 UTC #2

Ohne alles gelesen zu haben… Klingt das nach deinem Problem / einer Lösung?:

Stefan

schwendtke 2019-11-12 11:12:15 UTC #3

Danke für die Info Stefan, hab die Funktion angepasst, leider ohne Erfolg. Nächster Schritt nur zum Test: Wir binden mal ein “altes” Lightning ein. Melde mich wieder.
Jan

StefanU 2019-11-12 11:33:24 UTC #4

Du hast aber schon gesehen, dass der Fix für die aktuelle 19.1 ist? Wir müssten das ansonsten noch für die 17.1 zurück portieren.

@RalfBecker
Können wir das zurück portieren?
Oder ist das noch etwas anderes?

Stefan

RalfBecker 2019-11-12 12:10:25 UTC #5

Brauchen wir nicht zurück zu portieren, da das Problem nur in 19.1 existiert.

Wir haben in 19.1 den Default umgestellt, so das alle WebDAV, CalDAV oder CardDAV Clients jetzt ein vollständiges URL Encoding bekommen. Das hat leider ab TB 68 dazu geführt, dass Teilnehmer an einem Termin nicht mehr als solche erkannt wurden, da das @ in der EMail Adresse auch URL kodiert wurde.

Das hat mein Commit gestern behoben und ist für eine 17.1 nicht notwendig.

Was das Problem in dem Post ist, kann ich mit den gegebenen Informationen auch nicht sagen.

Ralf

schwendtke 2019-11-12 14:05:13 UTC #6

Nun, konnte mit TB 52.7.0 und Lightning 5.4.7 testen und das Verhalten ist genauso wie mit den neueren Versionen.

Ich vermute, wir haben in unserer Installation welche schon ganz paar Tage alt ist und mehrere Updates hinter sich hat ein Konfigurationsproblem. Was wiederum nicht dazu passt, dass es mit anderen Clients außer TB funktioniert.

Irgendwie steh ich nur auf´m Schlauch und bekomme den Ansatzpunkt nicht gegriffen… Mehr als oben benannte Fehlermeldungen finde ich nicht. Die Fehlerkonsole des TB gibt auch nur Hinweise auf 403 und der Apache ist recht schweigsam. Gleichzeitig kann ich nicht nachvollziehen, seit wann das Problem besteht, da der Fehler erst kürzlich an uns herangetragen wurde. Somit sind die Informationen, welche ich geben kann recht spärlich, ich weiß.

Wir wollen ja schon auch bald auf 19.1 wechseln, aber da fehlt momentan die Zeit.

Jan

StefanU 2019-11-12 14:28:41 UTC #7

Habe gerade mal getestet:
EGw 17.1.20190402 (!), TB 60.9.1, Lightning 6.2.9.1
Einladung erstellt, Eingeladene sagt über TB-Kalender zu = funktioniert

Welche 17.1 setzt ihr ein?
Hilft ein TB-Update auf die 60.9.1 (aktuell aus der 60.x)?

Mit einer 19.1 teste ich das später noch einmal.

Stefan

schwendtke 2019-11-12 14:33:09 UTC #8

Wir haben die 17.1.20190808.
Den TB auf 68.2.2 zu bringen, werden wir morgen mal in Angriff nehmen. Mal sehen welche Version passt.

Jan

StefanU 2019-11-12 16:04:05 UTC #9

Tritt das Problem denn nur bei einem TB-Benutzer oder bei mehreren Benutzen auf?

Stefan

schwendtke 2019-11-13 07:14:31 UTC #10

Also es tritt bei allen Nutzern auf. Habe jetzt den 68.2.2 getestet auch da kommt es zu identischen Fehlermeldung. Wir werden wohl nun doch, aus verschiedenen Gründen auf 19.1 gehen.

StefanU 2019-11-13 07:26:48 UTC #11

Wenn da aber vielleicht Murks in der Installation (Webserver, …) ist, würde ich nicht unbedingt die bestehende Installation kopieren/updaten. Ich habe da mal was dokumentiert:

Stefan

schwendtke 2019-11-13 09:16:54 UTC #12

Stimmt. Da sich unser Fehlerchen nicht genauer lokalisieren lässt, wollen wir geschichtlich entstandenen eventuellen “Murks” wie du es nennst, eben nicht mitnehmen, deswegen Neuinstall. Danke für die Doku… Eines fällt uns aber aus der Erinnerung ein, wir hatten schonmal die Problematik, dass wir die Gruppenverwaltung aus der Urinstallation nicht ohne weiteres mit in eine neue übernehmen konnten. Geht das noch?

Jan

StefanU 2019-11-13 10:08:24 UTC #13

Wie eh und je. Wenn du die Zugangsdaten zum Repo hast. Wenn ihr mit der 17.1 die Gruppenverwaltung nutzt, sollte das Repo ja in deiner aktuelle Installation drin stehen.

Link dazu:

Stefan

Änderungen im Docker

schwendtke 2019-11-13 10:35:01 UTC #14

Nun dann ist die Entscheidung es baldigst auf 19.1 zu bringen etwas einfacher geworden. Wir sind fast am Start.

Birger 2020-10-13 10:55:30 UTC #15

Ich bin hier auf TB 68.10.0 und EGroupware 20.1 und sehe das gleiche Problem. HTTP 403 bei Aktionen auf Einladungen wie Annehmen oder Alarm setzen. Ist das Problem wirklich behoben worden?