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.
(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 )
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
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
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)
Zunächst habe ich alle S3-Verweise aus der Datei web_only.yml entfernt. Danach ein Rebuild und zur Sicherheit rake posts:rebake. Die Probleme verschwanden, aber die Bilder kamen weiterhin über das CDN. Ich habe S3 wieder aktiviert, und das Problem war zurück.
Ich öffnete AWS und warf einen Blick auf die distribution-Einstellungen in CloudFront. Dort hatte ich mindestens eine Domain, die drei Jahre alt war und deren TLD sich in der Zwischenzeit geändert hatte. Ich finde es erstaunlich, dass überhaupt irgendetwas funktioniert hat. Ich habe die Einstellungen gemäß den CloudFront-Empfehlungen angepasst und an einer Stelle auch access-control-allow-origin: * gesetzt (was unsinnig ist, da es CORS praktisch obsolet macht). Allerdings wurde dieser Header, wie ich verstehe, bereits über CloudFront ausgeliefert.
Zur Sicherheit erneut ein Rebuild und Testen. Das half nicht.
Da es sein kann, dass der Cache stur ist, habe ich /assets/* und zur Sicherheit auch /assets/br/* invalidiert. Erneut Rebuild, und nun war das Problem behoben.
Ein weiteres Problem wurde ebenfalls gelöst. Seit dem Sommer hatte ich das Problem Oops…, also einen 50x-Fehler nach einem Rebuild. Wenn ich den Safe-Modus aktiviere und die Themes deaktiviere, kann ich mich im Admin-Bereich anmelden. Ich muss mehrere TCs, etwa 20 oder mehr, deaktivieren, damit das Forum wieder zum Leben erweckt wird. Danach kann ich diese Komponenten wieder aktivieren, und alles funktioniert wieder.
Können wir also den Schluss ziehen, dass alles auf Probleme mit AWS CloudFront zurückzuführen war?
Die Sache mit Oops ist ziemlich überraschend – ich hätte nicht damit gerechnet, dass das mit Cloudfront zu tun hat … Aber wenn es jetzt behoben ist … großartig!
Es bedeutet lediglich, dass dieses Asset aus einem Cross-Site-Kontext verwendet werden darf. Auf den eigentlichen HTTP-Antworten des Forums würde man diesen Header wahrscheinlich nicht setzen wollen. Aber bei statischen Assets, die keine Authentifizierung erfordern und keine privaten Informationen enthalten, ist das völlig in Ordnung. Genau so soll das CORS-System funktionieren – damit Server gezielt steuern können, welche Antworten cross-site verfügbar sein sollen.
Wenn man es wirklich möchte, könnte man Access-Control-Allow-Origin: my-forum.example.com setzen. Dann stößt man aber auf Probleme, falls man die Foren-Domain irgendwann ändert.