Les emojis personnalisés chargés depuis S3/R2 contournent le routage CDN

Vue d’ensemble

Lors de l’utilisation de S3 ou de Cloudflare R2 pour les téléchargements, en combinaison avec une URL de CDN personnalisée, les téléchargements d’émoticônes personnalisées ne respectent pas la configuration du CDN et tentent de charger directement depuis l’URL brute du bucket.

Le problème

Lorsqu’un administrateur télécharge une émoticône personnalisée, le téléchargeur crée un enregistrement upload et enregistre l’URL brute du bucket dans la base de données (par exemple, //my-bucket.s3.amazonaws.com/... ou //my-bucket.r2.cloudflarestorage.com/...) — c’est le comportement standard de Discourse.

Cependant, lorsque app/models/emoji.rb génère le cache d’émoticônes pour /site.json, il transmet directement upload.url à l’objet emoji :

e.url = emoji.upload&.url

Comme l’assistant du CDN est contourné, le frontend reçoit l’URL brute du bucket. Ainsi, selon la rigueur des politiques d’accès du bucket, cela entraîne des images brisées ou oblige Discourse à acheminer les émoticônes via le proxy interne avatar_proxy.

Solution

J’ai ouvert une PR qui encapsule les affectations d’URL dans Discourse.store.cdn_url(), ce qui permet au chargeur d’émoticônes personnalisées de s’aligner sur la façon dont les images de messages standards et les avatars sont acheminées.

Solution temporaire

En attendant que la PR soit examinée et fusionnée, j’ai créé un composant de thème léger qui remplace l’URL brute du bucket par l’URL CDN appropriée juste avant que l’émoticône personnalisée ne soit rendue dans le DOM (fonctionne pour les messages et le chat).

Si vous rencontrez ce bug sur votre site, vous pouvez installer ce composant et configurer vos chaînes S3 dans les paramètres de l’administration du thème pour corriger les émoticônes personnalisées brisées :

Remarque : si vous avez déjà téléchargé des émoticônes personnalisées qui sont actuellement brisées, l’exécution de discourse remap "//my-raw-bucket-url.com" "https://my-cdn.com" dans le conteneur corrigera les anciennes dans la base de données, tandis que le composant de thème corrigera toutes les nouvelles émoticônes téléchargées jusqu’à ce que la correction de la PR soit fusionnée dans le noyau.

3 « J'aime »

Test d’un jeu d’emojis par défaut

:smiley:

Test d’un emoji personnalisé

:falco:

oui, peut-être que c’est un problème spécifique à Cloudflare R2 alors. ça plante sur mon instance. ça semble seulement planter pour les nouveaux fichiers uploadés aussi.

sans la correction du composant de thème, je dois exécuter le remappage à chaque fois que j’upload un nouveau fichier. la PR pourrait avoir besoin d’un peu de travail - je ne suis pas super fort avec le code des emojis.

1 « J'aime »

Discourse utilise une configuration à deux CDN, l’un pour les ressources (assets) et l’autre pour faire office de proxy pour l’application.

Les emojis standards utilisent un CDN, les emojis personnalisés utilisent l’autre CDN, mais les deux sont protégés par un CDN sur un site correctement configuré avec une configuration à deux CDN fonctionnelle.

J’ai abordé ce point dans le premier sujet connexe ici :

Votre site dispose-t-il des deux CDN configurés et fonctionnels ?

2 « J'aime »

oh, je vais devoir y jeter un œil — je ne savais pas ça. merci !

édit :

j’ai rédigé la section pour Cloudflare R2, donc je suppose que ma configuration est correcte ? qu’est-ce que je pourrais avoir manqué ?

Je confirme ici que j’ai installé et testé la branche PR après les récents changements, et qu’elle corrige le problème.