SSO e avatares externos

Funcionalidade
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 curtida
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 curtida
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

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

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

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

9

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.

1 curtida