Kalendereinträge nicht sichtbar seit Update 23.1.20241128

[deme]

Hallo,

wir haben seit letzten Freitag das Version 23.1.20241128 in Verwendung. Seit diesem Update werden die Kalendereinträge nicht mehr angezeigt und die Kalender-UI sieht falsch aus. Wenn man folgendes durchführt, kann man die Kalendereinträge wieder sehen:

1. Öffne eGroupware in Firefox/Chrome/Vivaldi

2. Entwicklerkonsole mit F12 öffnen und zum Console-Tab wechseln

3. Einfügen: document.querySelector(’#calendar-toolbar’).style.height=‘100px’

4. Auf die Buttons 1, 7, etc. klicken bis der Kalender gezeigt wird. Wenn man in der 7-tägigen Ansicht ist, klickt man auf 1. Sonst auf 7. Wichtig scheint hier nur zu sein, dass sich die Art der Ansicht ändert um die Daten nachzuladen

Im Anhang sollten drei Bilder sein. Das erste zeigt die Darstellung des Kalenders, wenn man ihn im Browser öffnet. Das zweite Bild zeigt die Höhe der Kalenderwidgets beim Hovern über den DOM in der Entwicklerkonsole. Das dritte Bild zeigt die Kalendereinträge, nachdem man den beschrieben Workaround von oben genutzt hat.

[deme]

Weitere Details:

• Version: egroupware-docker (23.1.20241128)
• Installationsart: Debian-Paket, welches Docker konfiguriert
• Betroffenes Modul: Kalender
• Fehler trat mit Update 23.1.20241128 am 29.11.2024 bei unseren System auf.
• Bei welcher Aktion tritt der Fehler auf: Wenn man den Kalender in der eGroupware öffnet sieht man keine Kalendereinträge. Die UI für die Schnellauswahl nimmt die ganze Höhe des Kalender-Widgets ein. Siehe Screenshot.
• Ist der Fehler reproduzierbar? Ja, jedes mal mit Firefox, Vivaldi, Chrome.
• Sind Hinweise im Web-Server-Error-Log15 zu finden: Nein
• MariaDB auf dem Host
• Webserver: Reverse-Proxy Apache auf Debian 12-Host
• Welche PHP-Version: 8.3.14 im Original-eGroupware-Container

Hier noch ein paar Vermutungen.

Ich habe ein wenig im Forum herumgelesen und es wird der Push-Mechanismus gegenüber dem JSON-Fallback empfohlen. Push funktioniert momentan bei uns nicht, da ws:// statt wss:// verwendet wird. Ich habe leider nicht herausfinden können, wie ich die Canonical-URL ändern oder WSS auf eine andere Art erzwingen kann. Das egw-Skript hat jedenfalls nur eine ws://-URL angegeben.

In der Console im Browser stehen aber auch weitere Probleme (host. name. example. com ist natürlich ein Platzhalter für den echten Namen mit Subdomains):

GET https :// host.name.example.com/egroupware/manifest.json 401 (Unauthorized)
Manifest: Line: 1, column: 1, Syntax error.

Dann die angesprochene WebSocket-Geschichte, die nicht wss nutzt:

egw_json.js:132 Mixed Content: The page at ‘https://host.name.example.com/egroupware/index.php?cd=yes’ was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint ‘ws :// host.name.example.com/egroupware/push’. This request has been blocked; this endpoint must be available over WSS.

Etwas später wird folgende Anfrage erzeugt:

GET https :// host.name.example.com/egroupware/null 404 (Not Found)

Anmerkung: Aufgrund des Link-Limits und Bilder-Limits für neue Nutze habe ich die Bilder in ein Bild gepackt und auch einige Links hier mit Leerzeichen versehen müssen.

[StefanU]

Hi Dennis.

Anmerkung: Aufgrund des Link-Limits und Bilder-Limits für neue Nutze habe ich die Bilder in ein Bild gepackt und auch einige Links hier mit Leerzeichen versehen müssen.

Habe dich mal hoch gestuft.

---

Seit diesem Update werden die Kalendereinträge nicht mehr angezeigt und die Kalender-UI sieht falsch aus.

Ist sicher kein generelles Problem. Wir haben keinerlei derartige Rückmeldungen.

Caches löschen (Browser, Web-Proxy, EGw) hast du vermutlich durch geführt?

Stefan

[deme]

Hallo Stefan,

danke für die Hochstufung. Folgendes habe ich getan:

1. Container neugestartet
2. Verschiedene Browser (Chrome, Firefox, Vivaldi) bei verschiedenen Nutzer ausprobiert. Das Problem existiert auch im Privaten Modus der verschiedenen Browser
3. Cache in der EGroupware geleert via Admin → Clear cache and register hooks
4. Webserver/Reverse Proxy neugestartet

Bei Punkt 3. erhalte ich folgende meldung:

(Grüne Box) Done

(Rote Box) A request to the EGroupware server returned with an error: undefined (undefined)

Please reload the EGroupware desktop (F5 / Cmd+R).
If the error persists, contact your administrator for help and ask to check the error-log of the webserver.

URL: /egroupware/json.php?menuaction=admin.admin_hooks.ajax_clear_cache&errored=1
Date: Wed Dec 04 2024 13:24:14 GMT+0100 (Central European Standard Time)

Wenn ich https://host.name.example.com/egroupware/json.php?menuaction=admin.admin_hooks.ajax_clear_cache aufrufe (auch ohne ?menu…), erhalte ich das hier:

{“response”:,“page_generation_time”:“0.01”,“session_restore_time”:“0.01”}

[RalfBecker]

Ich habe ein wenig im Forum herumgelesen und es wird der Push-Mechanismus gegenüber dem JSON-Fallback empfohlen. Push funktioniert momentan bei uns nicht, da ws:// statt wss:// verwendet wird. Ich habe leider nicht herausfinden können, wie ich die Canonical-URL ändern oder WSS auf eine andere Art erzwingen kann. Das egw-Skript hat jedenfalls nur eine ws://-URL angegeben.

Liegt vermutlich am zusätzlichen Proxy, der muss zwingend:

• WebSockets unterstützen
• Header “X-Forwarded-Scheme: https” setzen
• X-Forwarded-For Header macht auch Sinn, ist hier aber nicht das Problem

Ralf

[deme]

Danke für den Hinweis. Bei Apache sieht das wie folgt aus (steht auch natürlich in /etc/egroupware-docker/apache.conf):

RequestHeader set X-Forwarded-Proto "https" env=HTTPS

Das hat das Problem nicht gelöst, aber wir haben die Lösung für den Kalender gefunden. Die WebSocket-Daten werden, soweit ich das nachvollziehen konnte, durch folgenden Eintrag bei uns ungültig:

SetOutputFilter         INFLATE;proxy-html;DEFLATE

Also haben wir diese Regel entfernt und nun funktioniert der Kalender. Der TestPush im Admin-Interface sieht allerdings immer noch nicht korrekt aus. Aber die Synchronisierung scheint bei dem Kalender korrekt zu funktionieren. Ich markiere das Thema als erledigt, da der Kalender nun funktioniert.