Quando si utilizza SSO con sso overrides avatar: true, Discourse sembra scaricare l’avatar e servirlo sempre in locale invece di collegarsi direttamente all’URL fornito.
Sarebbe più sensato permettere agli avatar di essere serviti direttamente dall’avatar_url fornito? Al momento, per ogni avatar visualizzato, si accede al backend di Discourse in modo piuttosto inutile. Forse questa potrebbe essere un’opzione SSO?
Se il problema è che gli avatar potrebbero scomparire, ciò potrebbe essere gestito con l’evento onerror dell’immagine che imposta il src di fallback sulla copia scaricata in locale (o mostra quella predefinita). Ciò che non so è se le immagini degli avatar troppo grandi possano essere limitate solo con CSS.
Credo che disabilitare download_remote_images_to_local dovrebbe risolvere il tuo problema, anche se ciò farà sì che le immagini all’interno dei post vengano servite in remoto invece che localmente.
Interessante. So che il plugin OIDC consente di sovrascrivere l’email ad ogni accesso; forse qualcosa di simile potrebbe essere possibile anche per la sovrascrittura dell’avatar tramite SSO.
Se l’avatar SSO è nel formato https://central.avatar.service/<username>, puoi utilizzare l’impostazione del sito external_system_avatars_url per abilitare questa funzionalità.
Non è il nostro caso (vengono serviti da S3) e è improbabile che siano solitamente in quel formato, in modo che possano essere memorizzati nella cache in modo efficiente.
A distanza di un paio d’anni, dato che penso di aver precedentemente frainteso qualcosa, ritengo che ci sia ancora un facile miglioramento delle prestazioni qui.
In precedenza pensavo che gli avatar fossero archiviati localmente (sul server Discourse stesso) e mi chiedevo perché non venissero serviti direttamente dall’URL dell’avatar esterno SSO invece di raggiungere Discourse. Tuttavia, dopo qualche indagine, ora vedo che gli avatar esterni provenienti dall’SSO sono già caricati nello storage di oggetti (ad esempio S3) e nelle diverse dimensioni richieste.
Quindi, se ho capito bene, attualmente Discourse sta inoltrando gli avatar dallo storage di oggetti al client. Tuttavia, questo comportamento sembra specifico per quando si utilizzano avatar esterni SSO, poiché gli avatar qui su meta provengono direttamente dallo storage di oggetti (con CDN). Ma quando si utilizza l’SSO con URL esterni, gli URL degli avatar sono nella forma
dove raggiunge rails per ogni avatar visualizzato (prima di essere memorizzato nella cache dal client).
E se ho capito il codice, c’è anche un’impostazione per consentire un reindirizzamento invece di inoltrarlo, ma a quel punto ha già raggiunto rails e il reindirizzamento aggiunge solo tempo al tempo di caricamento per il client.
Non sarebbe più veloce collegare semplicemente gli avatar allo storage di oggetti (potenzialmente servendoli da una CDN) liberando contemporaneamente alcune risorse rails? /cc @Falco
Non è così. Per impostazione predefinita, Discourse effettuerà il proxy delle richieste per le immagini del profilo, come vedi sul tuo sito.
Tuttavia, l’anno scorso abbiamo introdotto un’impostazione che può essere abilitata tramite ENV DISCOURSE_REDIRECT_AVATAR_REQUESTS=1 per attivare il comportamento che vedi qui.
