Miniaturas de chat eluden s3_cdn_url y usan URLs de bucket S3 sin procesar

Hice una configuración reciente del bucket de carga de Cloudflare R2 y las miniaturas de chat se rompieron. Así que investigué un poco, corregí rápidamente mi configuración y encontré este tema: Cloudflare R2 Image URL Display Issue: Detailed Explanation and Fix. De todos modos, revisé otras configuraciones de buckets de carga S3 y noté que el error no era realmente un problema específico de Cloudflare.


Descripción

Cuando se configura un almacenamiento de objetos externo S3 o compatible para cargas, las imágenes de miniatura de chat omiten la CDN y se cargan directamente desde la URL del bucket.

Para buckets externos compatibles con S3 seguros, como Cloudflare R2, las miniaturas de chat se rompen y no se muestran.

El problema subyacente es que el serializador de chat no logra aplicar la configuración s3_cdn_url a las miniaturas. En lugar de enrutar la imagen a través de la CDN configurada, filtra la URL interna cruda del bucket S3 directamente en las cargas útiles del navegador.

Pasos para reproducir

Esto es reproducible en Meta y otros sitios que utilizan buckets de carga S3:

  1. Publica una imagen en un chat o canal.
  2. Inspecciona la URL de la imagen de miniatura en la consola.
  3. Haz clic en la imagen para obtener la original más grande e inspecciona la URL.
  4. Compárala con la miniatura.

Aquí hay un ejemplo de un chat de Meta:

URL de la miniatura: desde el bucket

https://cdck-file-uploads-global.s3.dualstack.us-west-2.amazonaws.com/meta/optimized/4X/4/7/9/479815360e0e6e0cd9f4ba565891776e84aea532_2_375x500.jpeg

URL original: vía CDN

https://global.discourse-cdn.com/meta/original/4X/4/7/9/479815360e0e6e0cd9f4ba565891776e84aea532.jpeg

En la consola, el HTML de la miniatura <img... contiene data-large-src = URL de CDN de CloudFront y src = URL del bucket de AWS.

captura de pantalla

Impacto:

  • Para almacenamiento compatible con S3 como Cloudflare R2, que son seguros por defecto y bloquean el acceso no autenticado a los puntos de conexión crudos del bucket, las imágenes de miniatura de chat (optimizadas) se rompen.
  • Fugas de anchoa de banda para AWS y otros buckets de almacenamiento de objetos compatibles con S3 que permiten el acceso a puntos de conexión crudos del bucket, ya que el chat omite la CDN por completo; esto resulta en pagar tarifas de salida de S3 directas por todo el tráfico de miniaturas de chat.
  • Fuga de infraestructura: las URL de almacenamiento backend crudas (incluidos nombres de buckets internos y, a veces, IDs de cuenta) se exponen en las cargas útiles JSON del cliente.

PR:

Tengo un PR para solucionar el problema aquí:

https://github.com/discourse/discourse/pull/40419

Parece que Sam agregó getURLWithCDN a la vista previa del compositor de chat; sin embargo, no creo que llegue al flujo de chat.

Me pregunto si la corrección del compositor podría haber fallado para algunas configuraciones de S3 también, porque getURLWithCDN se cae ante discrepancias de protocolo (// vs https://). De todos modos, el PR anterior simplemente extiende el trabajo de Sam agregando los envoltorios al flujo y haciéndolo agnóstico al protocolo.

Solución temporal:

Antes de darme cuenta de que esto era más que un problema de Cloudflare, creé un componente de tema ligero. Intercepta los dominios S3 crudos en el DOM de Chat y los reemplaza por el dominio CDN correcto antes de que el navegador intente descargarlos. Esto enruta el tráfico correctamente y tapa la fuga de anchoa de banda. Lo adapté para que funcione con cualquier almacenamiento de objetos compatible con S3. Solo dos configuraciones: URL cruda del bucket S3 y URL CDN de S3.

https://github.com/Lillinator/chat-s3-thumbnails-fix

(no tengo idea de por qué las oneboxes de GitHub están rotas aquí) Corregido ahora

5 Me gusta

Probablemente relacionado con el cambio de sitio… Acabo de volver a hornear.

2 Me gusta

Hola, ¿ya se ha fusionado la PR?

gracias

2 Me gusta

solo está pendiente de la revisión de un miembro del equipo humano después de que mi compañero discourse-triage-bot corrigiera algunas pruebas :slight_smile:

5 Me gusta

parece que ya se ha fusionado.

4 Me gusta

abierto por solicitud del autor

De acuerdo con los sitios que tienen emojis personalizados agregados, ahora estarán rotos en el chat una vez que se haya fusionado la corrección.

A diferencia de las imágenes estándar de los mensajes (que se pueden corregir con rake posts:rebake), los emojis personalizados del chat se pasan al frontend dinámicamente a través de /site.json.

Si tu base de datos contiene URLs de S3 que carecen del protocolo (por ejemplo, //bucket.endpoint...) o utilizan un dominio de estilo virtual-hosted que no coincide perfectamente con las variables de entorno de tu app.yml, el reemplazador CDN interno de Discourse falla silenciosamente. La URL del bucket sin procesar se pasa al navegador, lo que rompe los emojis personalizados en el chat.

Cómo solucionarlo:

Para corregir esto de forma permanente, necesitas volver a mapear forzosamente las URLs del bucket sin procesar a tu URL de CDN en la base de datos y, a continuación, borrar la caché del sitio para que /site.json se regenere.

1. Entra en tu contenedor:

Conéctate por SSH a tu servidor y entra en el contenedor de Discourse (normalmente app, o web_only si tienes una configuración de dos contenedores).

cd /var/discourse
./launcher enter app

2. Vuelve a mapear las URLs:

ejecuta la herramienta integrada de Discourse remap. Deberías ejecutarla dos veces para capturar tanto la variante https:// como la variante sin protocolo // que el script de migración a veces deja atrás.

reemplaza los marcadores de posición con tu URL real del bucket sin procesar y tu URL real de CDN:

# corrige las URLs estándar https://
discourse remap "https://<your-bucket>.<your-endpoint>.com" "https://cdn.your-domain.com"

# corrige las URLs sin protocolo // (esta es la que suele romper los emojis personalizados)
discourse remap "//<your-bucket>.<your-endpoint>.com" "https://cdn.your-domain.com"

3. Limpia la caché

Dado que /site.json está muy cacheado, debes limpiar la caché de Rails para forzar al foro a servir las nuevas URLs:

abre la consola de Rails:

rails c

ejecuta estos comandos:

Rails.cache.clear
Site.clear_cache
exit

4. Actualiza

Actualiza forzosamente tu navegador (y desactiva la solución alternativa del componente del tema si aún la estás usando). Los emojis personalizados en el chat ahora deberían estar corregidos y cargarse correctamente a través de la CDN.

3 Me gusta

Hola Lilly, muchas gracias por tu excelente trabajo. Ahora, mis subidas antiguas y las miniaturas funcionan como se esperaba después de los dos reasignaciones. Antes de eso, ni siquiera las imágenes de “/admin/config/customize/themes” funcionaban. Ahora todo está arreglado. Qué bien.

Gracias

1 me gusta