Nov 2019
12 / 15
Nov 2019
Oct 2020
schwendtke
Nov '19

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!

  • created

    Nov '19

  • last reply

    Oct '20
  • 14

    replies

  • 5.1k

    views

  • 4

    users

  • 7

    links

  • 6
schwendtke
Nov '19

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

StefanUEGroupware GmbH
Nov '19

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

RalfBeckerEGroupware GmbH
Nov '19

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
Nov '19

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

StefanUEGroupware GmbH
Nov '19

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
Nov '19

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

schwendtke
Nov '19

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.

StefanUEGroupware GmbH
Nov '19

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
Nov '19

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

StefanUEGroupware GmbH
Nov '19

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

schwendtke
Nov '19

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

11 months later
Birger
Oct '20

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?