Android-Geräte können RTE nicht nutzen, i-Geräte können den Modus des Compositors nicht ändern

Für mich klingt das nach einem Bug, aber dann müsste es hier ein Thema dazu geben. Wenn also mein Forum das einzige ist, liegt das Problem wohl auf meiner Seite.

Nun ja.

Meine Android-Nutzer können die virtuelle Tastatur nicht sehen, wenn sie den Rich-Text-Editor verwenden. Wenn ich auf Markdown umstelle, funktioniert alles einwandfrei. iPads und iPhones (Safari/PWA, DiscourseHub) sind auf Markdown festgelegt und können nicht auf RTE umgestellt werden.

Das hat, wie ich vermute, vor zwei Tagen angefangen. Meine Nutzer haben die Angewohnheit, erst abzuwarten, bevor sie mir sagen, dass etwas nicht funktioniert.

Was noch… selbst gehostet, 2-Container-Setup, auf dem neuesten Stand und wird täglich aktualisiert. Das aktuellste Update ist zum Zeitpunkt des Schreibens 20 Minuten alt. Der Safe-Mode hilft nicht.

Was ist mein nächster Schritt? Die Konsole und mögliche Fehlermeldungen sind auf Mobilgeräten keine Option.

Das sind sie schon, aber du musst das Gerät mit einem Laptop verbinden.

Ich habe das mit meinem Tablet (Android, Problem wie oben beschrieben) gemacht und sehe

(index):1 Access to script at 'https://cdnfoorumi.katiska.eu/assets/br/chunk-coedl1gv.digested.js' from origin 'https://foorumi.katiska.eu' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
prosemirror-editor-opfbo6zd.digested.js:1  GET https://cdnfoorumi.katiska.eu/assets/br/chunk-coedl1gv.digested.js net::ERR_FAILED 200 (OK)
d-editor.gjs:212 Uncaught (in promise) TypeError: Failed to fetch dynamically imported module: https://cdnfoorumi.katiska.eu/assets/br/prosemirror-editor-opfbo6zd.digested.js

Prosemirror ist der RTEditor. Aber ich kann dir nicht weiterhelfen, als die Fehlermeldung, die ich sehe, mit dir zu teilen.


Nebenbei: Danke für den Lacher über deine Kategorie „Küsse und Tiere“ (Leider sagt die englische Übersetzung stattdessen „cats“, also bleibe ich bei der deutschen Version :wink: )

Ich habe folgendes hinzugefügt:

DISCOURSE_ENABLE_CORS: true

Danach habe ich web_only.yml neu geladen und in CORS origins die Einträge https://foorumi.katiska.eu und https://cdnfoorumi.katiska.eu ergänzt.

Kein Erfolg.

Dann habe ich folgenden Befehl ausgeführt:

curl -sI -H 'Origin: https://foorumi.katiska.eu' 'https://cdnfoorumi.katiska.eu/assets/br/chunk-coedllgv.digested.js'

HTTP/2 403 
content-type: application/xml
access-control-allow-origin: *
access-control-allow-methods: GET, HEAD
access-control-max-age: 3000
server: AmazonS3
date: Thu, 10 Sep 2026 14:13:35 GMT
x-cache: Error from cloudfront
via: 1.1 <characters>.cloudfront.net (CloudFront)
x-amz-cf-pop: HEL51-P1
x-amz-cf-id: <characters>

Ich verstehe nicht, was hier los ist. Liegt das Problem an S3 und meinen dortigen Einstellungen? Wenn ja, warum ist das erst jetzt aufgetaucht? Ein Symptom könnte sein, dass ich seit gestern keine Forennotizen mehr schreiben kann.

Aber wenn CORS das Problem ist, warum sind dann nur diese betroffen?


Warum hat die KI in diesem Kontext ausgerechnet Küsse verwendet :rofl:

Ich glaube nicht, dass es kürzlich Änderungen an Discourse gab, die dies verursacht haben. S3 hat jedoch ein langjähriges seltsames Verhalten im Zusammenhang mit CORS, das dazu führen kann, dass CDNs eine Version des Assets ohne den Access-Control-Allow-Origin-Header cachen. Und wenn es sich um ein Problem mit einem fehlerhaften Cache handelt, könnte das erklären, warum nur einige deiner Benutzer betroffen sind (vermutlich basierend auf ihrem Standort).

Sofern ich mich recht erinnere: S3 liefert den Access-Control-Allow-Origin-Header nur für Anfragen, die einen Origin-Header senden (d. h. solche von einem normalen Webbrowser). Wenn Access-Control-Allow-Origin weggelassen wird, liefert S3 auch keinen Vary: origin-Header in seiner Antwort. Und so: Wenn die erste Anfrage für ein bestimmtes Asset aus einem Kontext außerhalb des Webbrowsers gesendet wird (z. B. curl oder ein Webcrawler), kann das CDN die Version ohne den CORS-Header cachen. Sehr nervig!

Die Einstellung DISCOURSE_CORS hilft hier überhaupt nicht. Sie ist nur für den Anwendungsserver relevant, nicht für S3.

Bei unserem Hosting umgehen wir dieses Problem, indem wir CloudFront so konfigurieren, dass Access-Control-Allow-Origin: * zu allen Antworten hinzugefügt wird. Das stellt sicher, dass das seltsame Verhalten von S3 nicht dazu führen kann, dass ein fehlerhaftes Ergebnis gecacht wird.

Alternativ könntest du CloudFront so konfigurieren, dass der Origin-Anfrageheader in seinen Cache-Key aufgenommen wird, wodurch die Antworten ohne CORS von den Antworten mit CORS getrennt gehalten werden.

Amazon hat eine Reihe von Dokumentationen zu CORS hier. Ich hatte diesen Link in meinen Notizen, der offenbar ein Forenthread zu genau diesem Problem war … aber es scheint, als hätten sie ihn gelöscht :cry:

Aber ich benutze Cloudfront nicht, also muss es von AWS kommen?

Bist du dir sicher? :eyes:

❯ host cdnfoorumi.katiska.eu
cdnfoorumi.katiska.eu is an alias for djpzno7cbajfp.cloudfront.net.

Edit: Zur Klarstellung: Wir sprechen hier von AWS Cloudfront, nicht von Cloudflare (die Namen sind sich super ähnlich! :sweat_smile:)

Ja, das stimmt — ich benutze tatsächlich AWS Cloudfront :laughing: Wenn ich mich recht erinnere, braucht man dafür eine eigene Domain. Oder so.

Ja, genau – das ist für eine benutzerdefinierte Domain erforderlich und macht die Sache auch günstiger (Cloudfront-Egress ist günstiger als direkter S3-Egress, wenn ich mich recht erinnere)