Bei der Verwendung von SSO mit sso overrides avatar: true lädt Discourse den Avatar herunter und bietet ihn stets lokal an, anstatt direkt auf die bereitgestellte URL zu verlinken.
Wäre es nicht sinnvoller, Avatare direkt von der bereitgestellten avatar_url aus zu bedienen? So wird für jeden angezeigten Avatar unnötigerweise auf das Discourse-Backend zugegriffen. Vielleicht könnte dies eine SSO-Option sein?
Sollte die Sorge bestehen, dass Avatare verloren gehen könnten, ließe sich dies über das onerror-Ereignis des Bildes lösen, das die src auf die lokal heruntergeladene Kopie zurücksetzt (oder ein Standardbild anzeigt). Ich weiß jedoch nicht, ob zu große Avatar-Bilder allein mit CSS eingeschränkt werden können.
Ich bin der Meinung, dass das Deaktivieren von download_remote_images_to_local Ihr Problem lösen sollte, wobei Bilder in Beiträgen dann jedoch statt lokal remote geladen werden.
Interessant. Ich weiß, dass das OIDC-Plugin es ermöglicht, die E-Mail-Adresse bei jedem Login zu überschreiben. Vielleicht wäre etwas Ähnliches auch möglich, um Avatare durch SSO überschreiben zu lassen.
Wenn das SSO-Avatar im Format https://central.avatar.service/<username> vorliegt, können Sie die Site-Einstellung external_system_avatars_url verwenden, um diese Funktion zu aktivieren.
Das ist bei uns nicht der Fall (sie werden von S3 bereitgestellt) – und es ist auch unwahrscheinlich, dass sie normalerweise in diesem Format vorliegen, damit sie effizient zwischengespeichert werden können.
Ich knüpfe hier ein paar Jahre später an, da ich glaube, dass ich zuvor etwas missverstanden habe, aber ich denke immer noch, dass hier ein einfacher Leistungsgewinn erzielt werden kann.
Zuvor dachte ich, die Avatare würden lokal gespeichert (auf dem Discourse-Server selbst) und fragte mich, warum sie nicht direkt von der externen SSO-Avatar-URL bereitgestellt würden, anstatt Discourse zu treffen. Nach einigem Herumprobieren sehe ich jedoch jetzt, dass externe Avatare von SSO bereits in den Objektspeicher (z. B. S3) hochgeladen sind und in den erforderlichen mehreren Größen vorliegen.
Wenn ich das richtig verstehe, leitet Discourse derzeit Avatare vom Objektspeicher an den Client weiter. Dieses Verhalten scheint jedoch spezifisch für die Verwendung externer SSO-Avatare zu sein, da Avatare hier in Meta direkt vom (CDN-fähigen) Objektspeicher stammen. Aber bei der Verwendung von SSO mit externen URLs haben die Avatar-URLs das Format
wobei sie bei jedem angezeigten Avatar auf Rails treffen (bevor sie vom Client zwischengespeichert werden).
Und wenn ich den Code richtig verstehe, gibt es sogar eine Einstellung, die eine Umleitung anstelle einer Weiterleitung ermöglicht. Zu diesem Zeitpunkt hat es jedoch bereits Rails getroffen, und die Umleitung verlängert nur die Ladezeit für den Client.
Wäre es nicht schneller, Avatare einfach mit dem Objektspeicher zu verknüpfen (möglicherweise über ein CDN bereitgestellt) und gleichzeitig einige Rails-Ressourcen freizugeben? /cc @Falco
Das ist nicht der Fall. Standardmäßig leitet Discourse Anfragen für Avatare weiter, wie Sie auf Ihrer Website sehen.
Letztes Jahr haben wir jedoch eine Einstellung eingeführt, die über die Umgebungsvariable DISCOURSE_REDIRECT_AVATAR_REQUESTS=1 aktiviert werden kann, um das von Ihnen hier gesehene Verhalten auszulösen.
