Para um fórum totalmente privado (sem acesso anônimo), a falta de uma opção de mídia segura na configuração padrão de armazenamento local parece-me uma grande omissão. Não me surpreenderia se muitas pessoas que administram fóruns privados não percebessem que todos os anexos de suas postagens são publicamente acessíveis (se você souber a URL). Se o texto da minha postagem não pode ser acessado anonimamente, intuitivamente eu pensaria que os anexos da postagem também não podem.
Vale a pena abrir uma issue solicitando isso para ver que tipo de apoio receberia? Já existe uma? Essa questão específica é atualmente um impeditivo para o meu pequeno e limitado grupo, que está tentando implantar o Discourse em um ambiente onde já temos o hardware de hospedagem e não queremos pagar por armazenamento em nuvem (especialmente pelos preços do AWS S3) apenas para garantir que nossa mídia não seja visível anonimamente.
Além disso, perdoe a possível ingenuidade desta pergunta. Mas já existe suporte para buckets distintos para uploads e backups, certo? Seria difícil dar suporte a um terceiro bucket para uploads seguros? Uploads públicos vão para o bucket público, uploads seguros vão para o bucket seguro, e não seriam necessárias ACLs individuais de objetos. E se o status de segurança de um objeto mudar, ele poderia simplesmente ser movido entre os buckets?
Acho que é bastante trabalho. Pelo menos um dia de trabalho, mas talvez uma semana?
A hospedagem da Cdck, que financia o desenvolvimento, usa uploads no S3, então só interessam sites auto-hospedados que exigem login e não têm orçamento para o S3.
Se seus usuários virem links de compartilhamento para seus ativos, eles podem simplesmente baixá-los para compartilhá-los. Não parece ser um grande problema.
Não estou maluco(a) ao achar estranho que o texto das postagens seja protegido, mas os anexos não, certo?
Há uma grande diferença entre compartilhamento intencional e acidental. Obviamente, não há uma maneira real de prevenir o primeiro. Mas o segundo pode acontecer agora mesmo, simplesmente porque as pessoas não entendem a tecnologia subjacente. Considere notificações por e-mail para postagens que incluem links para imagens anexadas sendo encaminhadas inocentemente para não membros. Uma opção para remover anexos em e-mails que não esteja vinculada à funcionalidade de mídia segura pode ser uma boa alternativa.
Mesmo quando as pessoas compartilham intencionalmente links de anexos, elas podem simplesmente ter esquecido que eram de uma categoria protegida. Mas, em um mundo ideal, o link do anexo não deveria ter valor para quem não tem acesso àquela categoria.
Um bug atual ou futuro em uma das implementações do S3 também poderia permitir, potencialmente, a enumeração anônima de recursos em um bucket ou a capacidade de adivinhar e fazer força bruta em URLs de objetos. Em um mundo ideal, eu gostaria que minha interface S3 on-premises fosse protegida por firewall contra a internet em geral, de modo que apenas o servidor Discourse pudesse acessá-la diretamente.
Não está maluco. Implementar uploads seguros para configurações que não usam S3 certamente não é algo contra o qual eu esteja. É apenas que não temos urgência ou pressão para construir esse recurso e a mudança não é trivial.
Ocasionalmente, temos estagiários e projetos de audição; este é certamente um tipo de projeto que poderia se encaixar em uma dessas categorias.
Tenho uma solução rápida que, acredito, proporcionaria uploads seguros para sites que exigem login.
Basicamente, você configura Authentication Based on Subrequest Result | NGINX Documentation para uploads. O único problema é que não consigo encontrar uma URL que retorne um 403/401 quando o requisito de login está ativado, então acessar um upload sem estar logado resulta em um erro 500. Isso só aconteceria se alguém tivesse uma URL de upload e tentasse acessá-la sem estar logado, então não parece ser tão grave.
É algo assim:
# JP
location = /auth {
internal;
proxy_pass http://discourse/categories;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
# END JP
location ~ ^/uploads/ {
auth_request /auth; #$JP
# NOTA: é realmente irritante que não possamos definir cabeçalhos
# no nível superior e herdar.
#
Não temos planos de criar funcionalidade de bucket distinta para uploads seguros, nem de fazer com que uploads seguros funcionem com configurações que não sejam S3 ou configurações sem ACLs. Podemos considerar fazer isso no futuro se houver demanda suficiente para justificar o investimento de tempo e recursos nessa iniciativa.
Por que está usando https://hashhackersforum.s3.us-east-2.amazonaws.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc em vez de https://forum.cdn.hashhackers.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc, se eu inseri a URL do CDN corretamente?
Não me importo de ignorar, mas temos a mídia segura ativada, o que significa que não é possível usar um CDN. Essa mensagem provavelmente não deveria ser exibida em sites com secure_media ativado.
Isso é legal. Não ficou claro para mim que o Discourse trataria os arquivos estáticos de forma diferente. Acredito que preciso reler todos os tópicos aqui novamente.
Ah… mais um lugar que está marcando uploads como seguros indevidamente. As insígnias não devem ser marcadas como seguras, pois são essencialmente imagens públicas, como avatares, logotipos de categorias e outras coisas. Vou precisar fazer uma correção para garantir que as imagens das insígnias não sejam marcadas como seguras e criar um script de migração que corrija aquelas que já estão marcadas como seguras.
Fico surpreso que isso estivesse funcionando para você de alguma forma; nada na versão 2.8.0 deveria ter afetado isso.
Obrigado pela sua resposta. Esta é a minha primeira vez usando Ruby e estou encantado com o quão clara essa linguagem pode ser. Após algumas horas depurando, acredito que descobri onde procurar. Acredito que fiz o oposto do que você disse Adicionei algumas linhas ao modelo Badge e agora ele consegue carregar as imagens. Também notei que temos uma flag for_site_setting ali. Acredito que ela usa essa informação para ajustar o ACL para objetos no S3, e definir false para essa coluna.
app/models/badge.rb
def image_url
if image_upload_id.present?
return upload_cdn_path(image_upload.url) if !image_upload.url.include?(SiteSetting.Upload.absolute_base_url)
uri = URI.parse(image_upload.url)
Rails.application.routes.url_for(
controller: "uploads",
action: "show_secure",
path: uri.path[1..-1],
only_path: true
)
end
end
Vou verificar o que mudará na próxima atualização para aprender mais sobre isso.
Você poderia me dizer qual é a melhor versão para usar em produção?
Obrigado!
Espero poder contribuir mais com a base de código no futuro.
A alteração que você fez no modelo de emblema certamente funcionará, e é ótimo que você tenha conseguido implementá-la na primeira vez que usou Ruby! No entanto, vou corrigir o problema central onde os emblemas não deveriam ser marcados como seguros.
Nossa branch tests-passed é a melhor versão para usar em produção, pois receberá todas as correções mais recentes assim que estiverem disponíveis, embora algumas pessoas prefiram permanecer na branch beta, que recebe correções e alterações a cada poucas semanas.
Avisarei você quando tiver a correção para os emblemas serem marcados como seguros.
…mas me pergunto se o problema está relacionado ao seu comentário aqui?
É suportado que usuários façam upload de avatares quando o upload de mídia segura está ativado? No momento, estou recebendo um erro, mas me pergunto se isso ocorre porque os avatares são enviados para o mesmo bucket onde o acesso público não é permitido…
1 curtida
Canapin
(Coin-coin le Canapin)
Dividiu este tópico
126
Eu renomeei recentemente “mídia segura” e configurações relacionadas para “uploads seguros”, pois não se aplica apenas a imagens/vídeos, etc., e todos geralmente se referem a isso como uploads seguros de qualquer maneira. O commit principal relevante está aqui:
O OP deste tópico foi atualizado para refletir isso.
Adicionei algumas linhas ao modelo Badge e agora ele consegue carregar as imagens. Também notei que temos uma flag for_site_setting ali. Acredito que ela usa essa informação para ajustar o ACL para objetos no S3, e definir false para essa coluna.