Ich habe kürzlich eine Cloudflare R2-Upload-Bucket-Konfiguration vorgenommen, und meine Chat-Vorschaubilder waren defekt. Also habe ich etwas recherchiert, eine schnelle Korrektur für meine Konfiguration vorgenommen und dabei dieses Thema gefunden: Cloudflare R2 Image URL Display Issue: Detailed Explanation and Fix. Wie auch immer, ich habe mir andere S3-Upload-Bucket-Konfigurationen angesehen und festgestellt, dass es sich bei dem Fehler nicht wirklich um ein Cloudflare-spezifisches Problem handelt.
Beschreibung
Wenn ein externer S3- oder kompatibler Objektspeicher für Uploads konfiguriert ist, umgehen Chat-Vorschaubilder das CDN und werden direkt von der Bucket-URL geladen.
Bei sicheren externen S3-kompatiblen Buckets wie Cloudflare R2 sind Chat-Vorschaubilder defekt und werden nicht angezeigt.
Das zugrundeliegende Problem besteht darin, dass der Chat-Serializer die Einstellung s3_cdn_url nicht auf Vorschaubilder anwendet. Anstatt das Bild über das konfigurierte CDN zu leiten, wird die rohe interne S3-Bucket-URL direkt in die Browser-Payloads geleckt.
Schritte zur Reproduktion
Dies ist auf Meta und anderen Sites, die S3-Upload-Buckets verwenden, reproduzierbar:
- Lade ein Bild im Chat oder in einem Kanal hoch.
- Untersuche die URL des Vorschaubilds in der Konsole.
- Klicke auf das Bild, um die größere Originalversion zu erhalten, und untersuche die URL.
- Vergleiche sie mit der des Vorschaubilds.
Hier ist ein Beispiel aus einem Meta-Chat:
Vorschaubild-URL: direkt vom Bucket
https://cdck-file-uploads-global.s3.dualstack.us-west-2.amazonaws.com/meta/optimized/4X/4/7/9/479815360e0e6e0cd9f4ba565891776e84aea532_2_375x500.jpeg
Original-URL: über das CDN
https://global.discourse-cdn.com/meta/original/4X/4/7/9/479815360e0e6e0cd9f4ba565891776e84aea532.jpeg
In der Konsole enthält das HTML des Vorschaubilds <img... das Attribut data-large-src mit der CloudFront-CDN-URL und src mit der AWS-Bucket-URL.
Auswirkungen:
- Bei S3-kompatiblen Speichern wie Cloudflare R2, die standardmäßig sicher sind und nicht-authentifizierten Zugriff auf rohe Bucket-Endpunkte blockieren, sind Chat-Vorschaubilder (optimiert) defekt.
- Bandlecks für AWS und andere S3-kompatible Objektspeicher-Buckets, die Zugriff auf rohe Bucket-Endpunkte erlauben, da der Chat das CDN vollständig umgeht; dies führt dazu, dass direkte S3-Egress-Gebühren für gesamten Chat-Vorschaubild-Datenverkehr anfallen.
- Infrastruktur-Lecks: Die rohen Backend-Speicher-URLs (einschließlich interner Bucket-Namen und manchmal Konten-IDs) werden in den Client-JSON-Payloads offengelegt.
Pull Request:
Ich habe einen PR zur Behebung des Problems hier eingereicht:
Es sieht so aus, als hätte Sam getURLWithCDN zum Chat-Composer-Vorschau hinzugefügt – jedoch scheint es, dass dies nicht in den Chat-Stream gelangt?
Ich frage mich, ob die Composer-Korrektur für einige S3-Konfigurationen ebenfalls fehlgeschlagen sein könnte, da getURLWithCDN bei Protokollmismatches (// vs. https://) abstürzt? Jedenfalls erweitert der oben genannte PR einfach Sams Arbeit, indem er Wrapper für den Stream hinzufügt und ihn protokollunabhängig macht.
Temporäre Workaround:
Bevor mir klar wurde, dass dies mehr als nur ein Cloudflare-Problem war, habe ich eine leichte Theme-Komponente erstellt. Sie fängt die rohen S3-Domains im Chat-DOM ab und tauscht sie vor dem Download durch den Browser gegen die korrekte CDN-Domain aus. Dies leitet den Datenverkehr korrekt um und schließt das Bandbreiten-Leck. Ich habe sie so angepasst, dass sie für jeden S3-kompatiblen Objektspeicher funktioniert. Es werden nur zwei Einstellungen benötigt: Raw S3 bucket URL und S3 CDN URL.
(keine Ahnung, warum die GitHub-Oneboxen hier defekt sind) jetzt behoben