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.

5 Me gusta

Probando un emoji predeterminado

:smiley:

Probando un emoji personalizado

:falco:

2 Me gusta

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.

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

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

2 Me gusta

1 me gusta

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

1 me gusta

Esta es la sección de la guía del wiki que escribí:

¿Tienes ambos configurados?

Esto es un artefacto de mover Meta de AWS de vuelta a Metal, le faltaba un nuevo cook, simplemente reconstruí el HTML para solucionarlo.

¿Tu sitio de prueba tiene ambas variables de entorno CDN configuradas?

3 Me gusta

Las tengo configuradas, pero por los amor de Dios, tenía un error tipográfico en mi configuración de Cloudflare para el registro DNS específico de la CDN al que apunta DISCOURSE_CDN_URL y nunca lo probé cuando lo configuré porque mi sitio funcionaba :laughing: qué desastre.

Al menos aprendí más sobre la creación de código de emoji con esa PR inútil…
:woman_facepalming:t2:

¡Gracias Falco!

3 Me gusta

¡Jaja, no te preocupes!

Así es como más aprendo, persiguiendo conejos que nunca llevarán a nada tangible. ¡Pero el conocimiento que se obtiene de eso es oro puro!

3 Me gusta

Vaya, qué aventura ha sido esto. Básicamente, reconfiguré todo mi almacenamiento de objetos Cloudflare R2 y mi instancia de Discourse, y creo que este error es legítimo para R2. Cuando corregí mi registro DNS de Cloudflare y reconstruí la instancia para que DISCOURSE_CDN_URL apuntara realmente a él, rompió un montón de otras cosas, como las cadenas de traducción, y lanzó múltiples errores en la consola, incluidos algunos errores de CORS. Esto me llevó por muchos caminos tortuosos hoy. Así que supongo que usar DISCOURSE_CDN_URL parece ser incompatible con Cloudflare R2. (Esto fue muy extraño: cuando configuré originalmente mi entrada DNS, ingresé incorrectamente el registro DNS de cdn.mysite.com de modo que se resolvía como cdn.mysite.com.mysite.com). Configurar DISCOURSE_CDN_URL correctamente parece ser incompatible con el almacenamiento de objetos Cloudflare R2. Puede que haya otras cosas que no entiendo del todo aquí.

En cualquier caso, cuando reconstruyo con mi rama de PR, todo se soluciona porque envuelve la asignación en Discourse.store.cdn_url() para que las cargas de emojis personalizados sigan la misma lógica de enrutamiento y respaldo de CDN de S3 que las cargas de imágenes estándar de las publicaciones.

Reabrí la PR y edité la descripción. Pero supongo que si el equipo de Discourse decide no fusionarla, está bien, porque el componente de tema soluciona el problema a nivel de cliente. Tenga en cuenta que la corrección de la PR solo debería afectar las configuraciones de almacenamiento de objetos R2 para emojis personalizados y no otros servicios compatibles con S3 como AWS.

2 Me gusta

Este PR fue fusionado y los emojis personalizados ahora están corregidos cuando se usa el almacenamiento de objetos Cloudflare R2 para las cargas. He publicado una actualización sugerida a la documentación relevante de R2 aquí: Configure an S3 compatible object storage provider for uploads

3 Me gusta

El problema está resuelto; presenta un nuevo informe si vuelves a verlo.