Wenn S3 oder Cloudflare R2 für Uploads zusammen mit einer benutzerdefinierten CDN-URL verwendet werden, beachten Uploads benutzerdefinierter Emojis die CDN-Konfiguration nicht und versuchen, direkt von der rohen Bucket-URL zu laden.
Das Problem
Wenn ein Administrator ein benutzerdefiniertes Emoji hochlädt, erstellt der Uploader einen upload-Eintrag und speichert die rohe Bucket-URL in der Datenbank (z. B. //my-bucket.s3.amazonaws.com/... oder //my-bucket.r2.cloudflarestorage.com/...) – dies ist das Standardverhalten von Discourse.
Allerdings übergibt app/models/emoji.rb beim Generieren des Emoji-Caches für /site.json die upload.url direkt an das emoji-Objekt:
e.url = emoji.upload&.url
Da der CDN-Helfer umgangen wird, erhält das Frontend die rohe Bucket-URL. Je nach Strenge der Zugriffsrichtlinien des Buckets führt dies zu defekten Bildern oder zwingt Discourse dazu, die Emojis über den internen avatar_proxy zu leiten.
Lösung
Ich habe einen PR erstellt, der die URL-Zuweisungen in Discourse.store.cdn_url() einbettet, wodurch der Lader für benutzerdefinierte Emojis mit der Weiterleitung von Standard-Bildbeiträgen und Avataren übereinstimmt.
Zwischenlösung
Während auf die Überprüfung und Zusammenführung des PR gewartet wird, habe ich ein leichtgewichtiges Theme-Component erstellt, das die rohe Bucket-URL durch die korrekte CDN-URL ersetzt, kurz bevor das benutzerdefinierte Emoji im DOM gerendert wird (funktioniert sowohl für Beiträge als auch für Chat).
Wenn du dieses Problem auf deiner Seite hast, kannst du dieses Component installieren und deine S3-Zeichenfolgen in den Theme-Admin-Einstellungen konfigurieren, um defekte benutzerdefinierte Emojis zu beheben:
Hinweis: Wenn du bereits benutzerdefinierte Emojis hochgeladen hast, die derzeit defekt sind, wird die Ausführung von discourse remap "//my-raw-bucket-url.com" "https://my-cdn.com" im Container die alten Einträge in der Datenbank beheben, während das Theme-Component alle neu hochgeladenen Emojis bis zur Zusammenführung der PR-Lösung im Core behebt.
Ja, vielleicht ist es nur ein Problem mit Cloudflare R2. Bei meiner Instanz kracht es. Es scheint nur bei neu hochgeladenen Dateien vorzukommen.
Ohne die Korrektur für das Theme-Element muss ich bei jedem Upload einer neuen Datei den Remap-Prozess ausführen. Der PR braucht vielleicht noch ein bisschen Arbeit – ich kenne mich mit dem Emoji-Code nicht so gut aus.
Discourse verwendet ein Zwei-CDN-Setup, eines für Assets und eines, das die App proxied.
Standard-Emojis verwenden das eine CDN, benutzerdefinierte Emojis das andere, aber beide sind durch ein CDN auf einer korrekt konfigurierten Website mit einem funktionierenden Zwei-CDN-Setup geschützt.
Das habe ich im ersten verwandten Thema hier erläutert:
Ist auf Ihrer Website beides CDN korrekt eingerichtet und funktioniert?
Ich habe sie zwar gesetzt, aber zum Teufel, ich hatte einen Tippfehler in meiner Cloudflare-Konfiguration für den CDN-spezifischen DNS-Eintrag, auf den DISCOURSE_CDN_URL zeigt, und ich habe es nie getestet, als ich es eingerichtet habe, weil meine Seite funktionierte was für ein Chaos.
Zumindest habe ich mehr über das Erstellen von Emoji-Codes gelernt, als ich diesen sinnlosen PR erstellt habe…
Wow, was für eine Fahrt das war. Ich habe im Grunde meine gesamte Cloudflare R2-Objekt-Speicher- und Discourse-Instanz neu konfiguriert, und ich glaube, dieser Bug ist tatsächlich ein Problem bei R2. Als ich meinen Cloudflare-DNS-Eintrag korrigiert und die Instanz neu aufgebaut habe, sodass DISCOURSE_CDN_URL tatsächlich darauf zeigte, hat das eine ganze Menge anderer Dinge durcheinandergebracht, wie zum Beispiel Übersetzungsstrings, und mehrere Fehler in der Konsole verursacht, darunter einige CORS-Fehler. Das hat mich heute durch viele Kaninchenlöcher geführt. Also scheint die Verwendung von DISCOURSE_CDN_URL inkompatibel mit Cloudflare R2 zu sein. (Das war sehr seltsam – als ich ursprünglich meinen DNS-Eintrag eingerichtet habe, hatte ich den cdn.mysite.com-DNS-Eintrag falsch eingegeben, sodass er als cdn.mysite.com.mysite.com aufgelöst wurde.) Die korrekte Einstellung von DISCOURSE_CDN_URL scheint inkompatibel mit Cloudflare R2-Objekt-Speicher zu sein. Es gibt hier wahrscheinlich noch andere Dinge, die ich nicht vollständig verstehe.
Jedenfalls, wenn ich mit meinem PR-Branch neu aufbaue, ist alles behoben, weil es die Zuweisung in Discourse.store.cdn_url() einbettet, sodass Uploads benutzerdefinierter Emojis denselben S3-CDN-Routing- und Fallback-Logiken folgen wie Standard-Post-Bild-Uploads.
Ich habe den PR wieder geöffnet und die Beschreibung bearbeitet. Aber wenn das Discourse-Team entscheidet, ihn nicht zu mergen, ist das in Ordnung, da das Theme-Component das Problem auf Client-Ebene behebt. Beachte, dass die PR-Behebung nur R2-Objekt-Speicher-Konfigurationen für benutzerdefinierte Emojis betreffen sollte und nicht andere reguläre S3-kompatible wie AWS.
Dieser PR wurde gemergt, und die benutzerdefinierten Emojis funktionieren jetzt korrekt, wenn Cloudflare R2-Objektstorage für Uploads verwendet wird. Ich habe hier einen Vorschlag zur Aktualisierung der entsprechenden R2-Dokumentung gepostet: Configure an S3 compatible object storage provider for uploads
was für ein Chaos.