Lors de l’utilisation de SSO avec sso overrides avatar: true, Discourse semble télécharger l’avatar et le servir systématiquement en local plutôt que de créer un lien direct vers l’URL fournie.
Serait-il plus logique de permettre aux avatars d’être servis directement depuis l’avatar_url fourni ? Dans l’état actuel des choses, chaque avatar affiché interroge inutilement le backend de Discourse. Peut-être pourrait-il s’agir d’une option SSO ?
Si la préoccupation est que les avatars puissent disparaître, cela pourrait être géré via l’événement onerror de l’image, qui bascule la propriété src vers la copie téléchargée localement (ou affiche une image par défaut). Ce que je ne sais pas, c’est si des images d’avatar trop volumineuses peuvent être contraintes uniquement avec du CSS.
Je pense que désactiver download_remote_images_to_local devrait résoudre votre problème, bien que cela serve également les images dans les publications à distance plutôt que localement.
Intéressant. Je sais que le plugin OIDC permet de remplacer l’adresse e-mail à chaque connexion. Peut-être qu’une chose similaire serait possible pour la mise à jour de l’avatar via SSO.
Si l’avatar SSO est au format https://central.avatar.service/<username>, vous pouvez utiliser le paramètre du site external_system_avatars_url pour activer cette fonctionnalité.
Ce n’est pas notre cas (ils sont servis depuis S3) — et il est peu probable qu’ils soient généralement dans ce format, afin de pouvoir être mis en cache efficacement.
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
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
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.
