Emojis personalizados cargados desde S3/R2 omiten el enrutamiento de CDN

Descripción general

Al utilizar S3 o Cloudflare R2 para las cargas junto con una URL de CDN personalizada, las cargas de emojis personalizados no respetan la configuración del CDN e intentan cargarse directamente desde la URL del bucket sin procesar.

El problema

Cuando un administrador carga un emoji personalizado, el cargador crea un registro de upload y guarda la URL del bucket sin procesar en la base de datos (por ejemplo, //my-bucket.s3.amazonaws.com/... o //my-bucket.r2.cloudflarestorage.com/...); este es el comportamiento estándar de Discourse.

Sin embargo, cuando app/models/emoji.rb genera la caché de emojis para /site.json, pasa la upload.url directamente al objeto emoji:

e.url = emoji.upload&.url

Dado que omite el helper del CDN, el frontend recibe la URL del bucket sin procesar. Por lo tanto, dependiendo de lo estrictas que sean las políticas de acceso del bucket, esto provoca que las imágenes no se muestren correctamente o obliga a Discourse a enrutar los emojis a través del avatar_proxy interno.

Solución

He abierto una PR que envuelve las asignaciones de URL en Discourse.store.cdn_url(), lo que hace que el cargador de emojis personalizados se alinee con la forma en que se enrutan las imágenes estándar de las publicaciones y los avatares.

Solución temporal

Mientras se espera a que la PR sea revisada y fusionada, he creado un componente de tema ligero que reemplaza la URL del bucket sin procesar por la URL correcta del CDN justo antes de que el emoji personalizado se represente en el DOM (funciona tanto para publicaciones como para chat).

Si estás experimentando este error en tu sitio, puedes instalar este componente y configurar tus cadenas de S3 en la configuración del administrador del tema para corregir cualquier emoji personalizado roto:

Nota: si ya has cargado emojis personalizados que actualmente están rotos, ejecutar discourse remap "//my-raw-bucket-url.com" "https://my-cdn.com" en el contenedor corregirá los antiguos en la base de datos, mientras que el componente del tema corregirá cualquier emoji cargado de nuevo hasta que la corrección de la PR se fusione en el núcleo.

3 Me gusta

Probando un emoji predeterminado

:smiley:

Probando un emoji personalizado

:falco:

Sí, quizás sea algo exclusivo de Cloudflare R2. Se están rompiendo en mi instancia. Solo parece fallar con los nuevos que subo.

Sin la corrección del componente del tema, tengo que ejecutar el remapeo cada vez que subo uno nuevo. El PR quizás necesite un poco de trabajo; no soy muy bueno con el código de emojis.

1 me gusta

Discourse utiliza una configuración de doble CDN, uno para los activos y otro para hacer proxy de la aplicación.

Los emojis estándar usan un CDN, los emojis personalizados usan el otro CDN, pero ambos están protegidos por un CDN en un sitio web configurado correctamente con una configuración de doble CDN funcional.

Lo revisé en el primer tema relacionado aquí

¿Tu sitio tiene ambos CDN configurados y funcionando?

2 Me gusta

oh, tendré que echarle un vistazo, no lo sabía. ¡Gracias!

edición:

escribí la sección para Cloudflare R2, así que asumo que lo tengo configurado correctamente, ¿verdad? ¿Qué podría estar pasando por alto?

Confirmo aquí que instalé y probé la rama del PR después de los cambios recientes y que soluciona el problema.