SSO et avatars externes

Fonctionnalité
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 « J'aime »
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 « J'aime »
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

Quelques années plus tard, je fais un suivi car je pense avoir mal compris quelque chose, cependant, je pense toujours qu’il y a une amélioration facile à faire ici en termes de performance.

Auparavant, je pensais que les avatars étaient stockés localement (sur le serveur Discourse lui-même) et je me demandais pourquoi ils n’étaient pas servis directement depuis l’URL externe de l’avatar SSO au lieu de passer par Discourse. Cependant, après quelques recherches, je vois maintenant que les avatars externes provenant du SSO sont déjà téléchargés dans le stockage objet (par exemple, S3) et dans les différentes tailles requises.

Donc, si je comprends bien, actuellement Discourse relaie les avatars du stockage objet vers le client. Cependant, ce comportement semble spécifique à l’utilisation des avatars externes SSO, car les avatars ici sur meta proviennent directement du stockage objet (servi par CDN). Mais lorsque vous utilisez le SSO avec des URL externes, les URL des avatars sont sous la forme

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

où cela atteint rails pour chaque avatar affiché (avant d’être mis en cache par le client).

Et si je comprends bien le code, il existe même un paramètre pour autoriser une redirection au lieu de la proxy, mais à ce moment-là, cela a déjà atteint rails et la redirection ne fait qu’ajouter du temps au temps de chargement pour le client.

Ne serait-il pas plus rapide de simplement lier les avatars au stockage objet (potentiellement servi par un CDN) tout en libérant certaines ressources rails en même temps ? /cc @Falco

9

Ce n’est pas le cas. Par défaut, Discourse relaie les requêtes pour les avatars, comme vous le voyez sur votre site.

Cependant, l’année dernière, nous avons introduit un paramètre qui peut être activé via la variable d’environnement DISCOURSE_REDIRECT_AVATAR_REQUESTS=1 pour déclencher le comportement que vous voyez ici.

1 « J'aime »