Al usar SSO con sso overrides avatar: true, Discourse parece descargar el avatar y siempre servirlo localmente en lugar de enlazar directamente a la URL proporcionada.
¿Tendría más sentido permitir que los avatares se sirvan directamente desde el avatar_url proporcionado? Tal como está, por cada avatar mostrado se accede innecesariamente al backend de Discourse. Quizás esto podría ser una opción de SSO.
Si la preocupación es que los avatares puedan desaparecer, eso podría manejarse con el evento onerror de la imagen, que haría que el src de respaldo apunte a la copia descargada localmente (o mostraría una por defecto). Lo que no sé es si las imágenes de avatar demasiado grandes pueden limitarse solo con CSS.
Creo que desactivar download_remote_images_to_local debería solucionar tu problema, aunque esto hará que las imágenes dentro de los mensajes se sirvan de forma remota en lugar de localmente.
Interesante. Sé que el plugin OIDC permite sobrescribir el correo electrónico en cada inicio de sesión; quizás algo similar sería posible para que los avatares también sean sobrescritos por SSO.
Si el avatar de SSO tiene el formato https://central.avatar.service/<username>, puedes utilizar la configuración del sitio external_system_avatars_url para habilitar esta función.
Haciendo un seguimiento de esto un par de años después, creo que anteriormente entendí algo mal, sin embargo, todavía creo que hay una victoria fácil aquí en cuanto al rendimiento.
Anteriormente, pensé que los avatares se almacenaban localmente (el propio servidor de Discourse) y me preguntaba por qué no se servían directamente desde la URL externa del avatar SSO en lugar de contactar a Discourse. Sin embargo, después de indagar un poco, ahora veo que los avatares externos que provienen del SSO ya se cargan en el almacenamiento de objetos (por ejemplo, S3) y en los múltiples tamaños requeridos.
Entonces, si entiendo correctamente, actualmente Discourse está proxyficando los avatares desde el almacenamiento de objetos al cliente. Sin embargo, este comportamiento parece ser específico de cuando se usan avatares externos SSO, ya que los avatares aquí en meta provienen directamente del almacenamiento de objetos (con CDN). Pero cuando se usa SSO con URL externas, las URL de los avatares tienen el formato
donde contacta a rails por cada avatar mostrado (antes de ser cacheados por el cliente).
Y si entiendo el código, incluso hay una configuración para permitir una redirección en lugar de proxyficarlos, pero en ese punto ya contactó a rails y la redirección solo agrega tiempo al tiempo de carga para el cliente.
¿No sería más rápido simplemente enlazar los avatares al almacenamiento de objetos (potencialmente sirviéndolos desde una CDN) mientras se liberan algunos recursos de rails al mismo tiempo? /cc @Falco
Ese no es el caso. Por defecto, Discourse proxyficara las solicitudes de avatares, como ves en tu sitio.
Sin embargo, el año pasado introdujimos una configuración que se puede habilitar a través de la variable de entorno DISCOURSE_REDIRECT_AVATAR_REQUESTS=1 para activar el comportamiento que ves aquí.
