Benutzerdefinierte Emojis, die von S3/R2 geladen werden, umgehen CDN-Routing

Beitragen Fehler
, ,
1

Übersicht

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.

3 „Gefällt mir“
2

Testen eines Standard-Emoji-Satzes

:smiley:

Testen eines benutzerdefinierten Emojis

:falco:

3

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.

1 „Gefällt mir“
4

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?

2 „Gefällt mir“
5

oh, ich muss mir das mal ansehen – das wusste ich nicht. Danke!

Edit:

Ich habe den Abschnitt für Cloudflare R2 geschrieben, also gehe ich davon aus, dass ich es richtig eingerichtet habe? Was könnte ich übersehen haben?

6

IMG_0127
IMG_01271724×975 100 KB

7

Ich bestätige hiermit, dass ich den PR-Branch nach den jüngsten Änderungen installiert und getestet habe, und er behebt das Problem.