J’ai récemment configuré un bucket de téléchargements Cloudflare R2 et mes miniatures de discussion ont été cassées. J’ai donc fait quelques recherches et apporté une correction rapide à ma configuration, puis j’ai trouvé ce sujet : Cloudflare R2 Image URL Display Issue: Detailed Explanation and Fix. Quoi qu’il en soit, j’ai examiné d’autres configurations de buckets de téléchargements S3 et constaté que le bug n’était pas vraiment spécifique à Cloudflare.
Description
Lorsqu’un stockage objet externe S3 ou compatible est configuré pour les téléchargements, les miniatures de discussion contournent le CDN et sont chargées directement depuis l’URL du bucket.
Pour un bucket S3 externe sécurisé et compatible, tel que Cloudflare R2, les miniatures de discussion sont cassées et ne s’affichent pas.
Le problème sous-jacent est que le sérialiseur de discussion échoue à appliquer le paramètre s3_cdn_url aux miniatures. Au lieu de router l’image via le CDN configuré, il expose directement l’URL brute interne du bucket S3 dans les charges utiles transmises au navigateur.
Étapes pour reproduire le problème
Ceci est reproductible sur Meta et d’autres sites utilisant des buckets de téléchargements S3 :
- Publiez une image dans une discussion ou un canal
- Inspectez l’URL de l’image miniature dans la console
- Cliquez sur l’image pour obtenir la version originale plus grande, puis inspectez l’URL
- Comparez-la à celle de la miniature
Voici un exemple provenant d’une discussion Meta
URL de la miniature : depuis le bucket
https://cdck-file-uploads-global.s3.dualstack.us-west-2.amazonaws.com/meta/optimized/4X/4/7/9/479815360e0e6e0cd9f4ba565891776e84aea532_2_375x500.jpeg
URL originale : via le CDN
https://global.discourse-cdn.com/meta/original/4X/4/7/9/479815360e0e6e0cd9f4ba565891776e84aea532.jpeg
Dans la console, le code HTML de la miniature <img... contient data-large-src = URL du CDN CloudFront, et src = URL du bucket AWS.
Impact :
- Pour les stockages compatibles S3 comme Cloudflare R2, qui sont sécurisés par défaut et bloquent l’accès non authentifié aux points de terminaison bruts du bucket, les miniatures de discussion (optimisées) sont cassées.
- Fuites de bande passante pour AWS et d’autres buckets de stockage objet compatibles S3 autorisant l’accès aux points de terminaison bruts du bucket, car la discussion contourne entièrement le CDN ; cela entraîne le paiement de frais de sortie S3 directs pour tout le trafic de miniatures de discussion.
- Fuite d’infrastructure : les URL brutes du stockage backend (y compris les noms de buckets internes et parfois les identifiants de compte) sont exposées dans les charges JSON du client.
PR :
J’ai une PR pour corriger le problème ici :
Il semble que Sam ait ajouté getURLWithCDN à l’aperçu du compositeur de discussion — cependant, je ne pense pas que cela atteigne le flux de discussion ?
Je me demande si la correction du compositeur a pu échouer pour certaines configurations S3, car getURLWithCDN plante en cas de mismatch de protocole (// vs https://) ? Quoi qu’il en soit, la PR ci-dessus étend simplement le travail de Sam en ajoutant des wrappers au flux et en rendant le tout indépendant du protocole.
Contournement temporaire :
Avant de réaliser que ce problème dépassait celui de Cloudflare, j’ai créé un composant de thème léger. Il intercepte les domaines S3 bruts dans le DOM de la discussion et les remplace par le bon domaine CDN avant que le navigateur ne tente de les télécharger. Cela route correctement le trafic et colmate la fuite de bande passante. Je l’ai adapté pour fonctionner avec n’importe quel stockage objet compatible S3. Il suffit de deux paramètres : URL brute du bucket S3 et URL CDN S3.
(je ne sais pas pourquoi les oneboxes GitHub sont cassées ici) corrigé maintenant