Ao usar SSO com sso overrides avatar: true, o Discourse parece baixar o avatar e sempre servi-lo localmente, em vez de vincular diretamente à URL fornecida.
Faria mais sentido permitir que os avatares sejam servidos diretamente a partir do avatar_url fornecido? Como está, para cada avatar exibido, há um acesso desnecessário ao backend do Discourse. Talvez isso pudesse ser uma opção de SSO?
Se a preocupação for que os avatares possam sumir, isso poderia ser tratado com o evento onerror da imagem, que faria o fallback do src para a cópia baixada localmente (ou exibiria uma padrão). O que não sei é se imagens de avatar muito grandes podem ser limitadas apenas com CSS.
Acredito que desabilitar download_remote_images_to_local deve resolver seu problema, embora isso também faça com que as imagens nos posts sejam servidas remotamente em vez de localmente.
Interessante. Sei que o plugin OIDC permite substituir o e-mail em cada login; talvez algo assim seja possível também para a substituição do avatar pelo SSO.
Se o avatar do SSO estiver no formato https://central.avatar.service/<username>, você pode usar a configuração do site external_system_avatars_url para obter esse recurso.
No nosso caso, não é o caso (eles são servidos do S3) — e é improvável que geralmente esteja nesse formato, para que possa ser armazenado em cache de forma eficiente.
Acompanhando isso alguns anos depois, pois acho que anteriormente entendi algo errado, no entanto, ainda acho que há uma vitória fácil aqui em termos de desempenho.
Anteriormente, eu pensava que os avatares estavam sendo armazenados localmente (o próprio servidor Discourse) e estava me perguntando por que eles não eram servidos diretamente do URL externo do avatar do SSO em vez de atingir o Discourse. No entanto, após algumas investigações, vejo agora que os avatares externos provenientes do SSO já estão carregados no armazenamento de objetos (por exemplo, S3) e nos vários tamanhos necessários.
Portanto, se entendi corretamente, atualmente o Discourse está encaminhando avatares do armazenamento de objetos para o cliente. No entanto, esse comportamento parece ser específico para quando se usam avatares externos do SSO, pois os avatares aqui no meta vêm diretamente do armazenamento de objetos (com CDN). Mas ao usar SSO com URLs externos, os URLs dos avatares estão no formato
onde ele atinge o rails para cada avatar exibido (antes de ser cacheado pelo cliente).
E se eu entendi o código, há até uma configuração para permitir um redirecionamento em vez de encaminhamento, mas nesse ponto ele já atingiu o rails e o redirecionamento apenas adiciona tempo ao tempo de carregamento para o cliente.
Não seria mais rápido simplesmente vincular os avatares ao armazenamento de objetos (potencialmente servindo-o de uma CDN) enquanto libera alguns recursos do rails ao mesmo tempo? /cc @Falco
Não é o caso. Por padrão, o Discourse fará proxy das solicitações de avatares, como você vê em seu site.
No entanto, no ano passado, introduzimos uma configuração que pode ser ativada via ENV DISCOURSE_REDIRECT_AVATAR_REQUESTS=1 para acionar o comportamento que você vê aqui.
