SSO y avatares externos

Característica
1

When using SSO with sso overrides avatar: true, Discourse seems to download the avatar and always serve it locally instead of linking directly to the URL provided.

Would it make more sense to allow avatars to serve directly from the avatar_url provided? As is, for each avatar shown it hits Discourse backend somewhat needlessly. Perhaps this could be a SSO option?

If the concern is that avatars may go missing, that could be handled with the image onerror event that fallback’s src to the locally downloaded copy (or show a default one). What I don’t know is if too large avatars images can be constrained with CSS alone.

1 me gusta
2

I believe disabling download_remote_images_to_local should solve your issue, although this will also serve images within posts remotely instead of locally.

3

That seems to be only for images in posts — or perhaps for local avatar too, when they are not overwritten by SSO.

1 me gusta
4

Interesting. I know that the OIDC Plugin allows you to override email on every login, maybe something like this would be possible for avatar’s being overwritten by SSO as well.

5

If the SSO avatar is in the format of https://central.avatar.service/<username> you can use the external_system_avatars_url site setting to get this feature.

6

It’s not in our case (they are served from S3) — and it’s unlikely to usually be in that format so that it can be efficiently cached.

8

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

https://discourse-host/user_avatar/discourse-host/{username}/{size}/{uploadid}_{version}.png

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

9

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í.

1 me gusta