Mi sitio de Discourse tiene muchas imágenes. Debido a la gran cantidad de imágenes, utilizo una combinación de S3/CDN para almacenar y servir imágenes. Dentro de la CDN, utilizo varias medidas para evitar el secuestro de imágenes. Una de las medidas es detener todo acceso directo a las imágenes y solo permitir el acceso desde una lista de nombres de host definidos.
Discourse funciona con esta configuración, excepto por los Avatares. Los Avatares dejan de funcionar cuando la protección contra hotlinking está activada.
La razón es que Discourse utiliza una configuración de proxy para los Avatares. El HTML utiliza un enlace proxy para los avatares. La estructura del enlace es https://discourse.forum/user_avatar/discourse.forums/username/24/616_2.png.
Una vez que se resuelve el proxy, el navegador solicita acceso directo al archivo de imagen.
Mi CDN evita el acceso directo con un 403 al realizar esta solicitud directa. Y todos los avatares personalizados se convierten en siluetas.
¿Qué opciones tenemos para eliminar el proxy?
¿Podemos cambiar el avatar a una estructura de archivo de imagen estándar?
El enlace de acceso directo se llama desde la dirección IP del usuario. El servidor resuelve la información, pero el navegador local realiza la llamada.
No estoy seguro de que funcione de esa manera. Dependiendo de tu configuración, el proxy realmente actúa como proxy o la CDN va primero. ¿Puedes explicar cómo está configurado esto?
Odio las preguntas vagas. ¿Qué estabas pensando cuando pediste “esto”?
Aquí están mis configuraciones actuales:
Configuración de Discourse:
Instalación estándar en un solo contenedor
Configurado como un subdominio: forums.domain.tld
Configuración estándar de S3 para subidas
Las subidas se guardan en S3
Configuración de S3:
Digital Ocean S3 Bucket
Bucket activado para acceso externo
Ninguna otra capa de seguridad o permisos
Configuración de CDN:
bunny CDN
Referentes permitidos configurados: domain.tld y *.domain.tld
El interruptor que mató el acceso a los avatares fue “Bloquear acceso directo a archivos URL”.
Cuando se activa, todos los avatares reciben un error 403. Cuando se desactiva, los avatares se muestran.
Imágenes que no son avatares:
URL en Discourse: https://cdn.domain.tld/optimized/3X/3/1/filename_#_size.jpeg
Imágenes de avatares:
URL en Discourse: https://forums.domain.tld/user_avatar/forums.domain.tld/mazzini/48/776_2.png
Una publicación anterior, ¿Cómo se almacenan y acceden a los avatares?, indica que Discourse utiliza un proxy para los avatares. Por lo tanto, la estructura de URL para los avatares no es una estructura de URL de imagen estándar.
Dentro de mi sistema, los avatares están disponibles desde S3 o desde la CDN. Esto indica que en algún lugar/de alguna manera la URL del avatar se convierte en una URL de CDN.
Cuando esto sucede, la CDN considera la URL como un enlace de acceso directo y bloquea el acceso con un 403.
Y odio que la gente responda así cuando dedico mi tiempo a ayudarles, así que eso nos deja en empate .
Sí, y “proxy” significa que la solicitud pasa a través de Discourse. La solicitud no la realiza el navegador a la CDN, sino Discourse.
¿Configuraste la CDN como una CDN de sitio completo o como la CDN de S3? Sospecho que lo último. Y en ese caso, la solicitud la realiza Discourse a la CDN, sin remitente. Pero la CDN aún puede reconocer que es una solicitud legítima porque la solicitud se origina en la IP de Discourse. De ahí mi consejo de incluirla en la lista blanca.
Editar: podrías comprobarlo desactivando la protección durante un corto período de tiempo y mirando los registros en Bunny, y ver de qué IP provienen.
Agradezco tu ayuda. Después de muchas décadas trabajando en desarrollo y soporte de TI, las preguntas y respuestas vagas crean más trabajo del necesario. Basado en tu experiencia, creo que estarías de acuerdo.
La CDN solo está configurada para el bucket S3.
Revisé los registros de la CDN para la IP de Discourse relacionada con los errores 403 antes de enviar el tema original. No estaba en los archivos de registro.
Basado en tus comentarios, volví y reanalicé los registros. Después de revisar los mayores infractores de IP, encontré que los dos principales son las pasarelas de la empresa de alojamiento.
El desafío es que no quiero tener que hacer un seguimiento de las direcciones IP de las pasarelas de Digital Ocean para que mi servidor Discourse pueda mostrar las imágenes correctamente.
.