Sim, temos essa GlobalSetting, que você pode habilitar definindo a variável de ambiente DISCOURSE_REDIRECT_AVATAR_REQUESTS=true
Então, em vez de fazer proxy, as requisições de avatar serão atendidas com um redirecionamento 302 para o armazenamento de arquivos.
Por si só… isso não é realmente uma boa ideia. Significa que os navegadores terão que fazer duas viagens completas de ida e volta HTTP para cada avatar. Portanto, embora possa resolver seu problema de ‘proteção contra hotlinking’… eu não recomendaria habilitá-lo. Isso tornará a experiência pior para seus usuários.
Usamos a configuração em nossa hospedagem discourse.org. Mas a complementamos com uma função lambda rodando em nosso CDN Cloudfront. Ela detecta o 302 e faz o proxy por si mesma. Essencialmente: movemos o proxy de nossos servidores de aplicação para o CDN.
Quanto à questão mais geral de “podemos mudar os avatares para linkar diretamente para o asset”. É complicado porque os URLs de avatar estão embutidos em todas as postagens históricas (por exemplo, citações). Os URLs dinâmicos /user-avatar/ nos permitem mantê-los funcionando quando um usuário altera seu avatar. Receio que não tenhamos planos de mudar esse sistema.
Se houver uma maneira fácil e de baixo risco de fazer o proxy existente funcionar para seu caso de uso (por exemplo, adicionar uma GlobalSetting que insira um cabeçalho HTTP específico em quaisquer requisições de proxy de avatar), então poderíamos considerar aceitar um PR para a mudança.