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

Contribuer Bug
, , ,
1

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.

5 « J'aime »
2

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

:smiley:

Test d’un emoji personnalisé

:falco:

2 « J'aime »
3

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.

2 « J'aime »
4

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 ?

4 « J'aime »
5

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é ?

2 « J'aime »
6

IMG_0127
IMG_01271724×975 100 KB

1 « J'aime »
7

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.

1 « J'aime »
8

Voici la section du guide wiki que j’ai rédigée :

Avez-vous configuré les deux ?

Ceci est un artefact lié au transfert de Meta d’AWS vers Metal. Une nouvelle recette (cook) manquait, j’ai simplement reconstruit le HTML pour le corriger.

Votre site de test a-t-il les deux variables d’environnement CDN configurées ?

3 « J'aime »
9

Je les ai bien définies, mais bon sang, j’avais fait une faute de frappe dans ma configuration Cloudflare pour l’enregistrement DNS spécifique au CDN que DISCOURSE_CDN_URL pointe, et je ne l’ai jamais testé lors de sa mise en place parce que mon site fonctionnait :laughing: quel cirque.

Au moins, j’ai appris plus sur la création de code pour les emojis que ce PR inutile…
:woman_facepalming:t2:

Merci Falco !

3 « J'aime »
10

Haha, pas de souci !

C’est ainsi que j’apprends le plus, en suivant des chemins de lapins qui ne mènent à rien de concret. Mais les connaissances acquises là-bas sont précieuses !

3 « J'aime »
11

waouh, quelle aventure. j’ai essentiellement reconfiguré tout mon stockage d’objets Cloudflare R2 et mon instance Discourse, et je pense que ce bug est bien réel pour R2. lorsque j’ai corrigé mon enregistrement DNS Cloudflare et reconstruit l’instance afin que DISCOURSE_CDN_URL pointe correctement vers lui, cela a cassé un tas d’autres choses, comme les chaînes de traduction, et a généré plusieurs erreurs dans la console, y compris des erreurs CORS. cela m’a mené dans de nombreux culs-de-sac aujourd’hui. donc, apparemment, utiliser DISCOURSE_CDN_URL semble incompatible avec Cloudflare R2. (c’était très étrange — lorsque j’ai initialement configuré mon enregistrement DNS original, j’avais incorrectement entré l’enregistrement DNS cdn.monsite.com de sorte qu’il résolvait en cdn.monsite.com.monsite.com). définir correctement DISCOURSE_CDN_URL semble incompatible avec le stockage d’objets Cloudflare R2. il y a peut-être d’autres aspects que je ne comprends pas entièrement ici.

bon, lorsque je reconstruis avec ma branche PR, tout est corrigé car elle enveloppe l’attribution dans Discourse.store.cdn_url() afin que les téléchargements d’emojis personnalisés respectent la même logique de routage CDN S3 et de repli que les téléchargements d’images de publication standards.

j’ai rouvert la PR et modifié la description. mais si l’équipe Discourse choisit de ne pas la fusionner, ce n’est pas grave car le composant thème corrige le problème au niveau client. Notez que la correction de la PR ne devrait affecter que les configurations de stockage d’objets R2 pour les emojis personnalisés et non les autres configurations compatibles S3 comme AWS.

2 « J'aime »
12

Cette PR a été fusionnée et les emoji personnalisés sont maintenant corrigés lors de l’utilisation du stockage d’objets Cloudflare R2 pour les téléchargements. J’ai posté une mise à jour suggérée pour la documentation R2 pertinente ici : Configure an S3 compatible object storage provider for uploads

3 « J'aime »
15

Le problème est résolu. Ouvrez un nouveau rapport si vous le revoez.