Como o Discourse não utiliza o Apache, como proteger com senha, por exemplo, um ambiente de staging (droplet Digital Ocean com Discourse Docker) da mesma forma que se faria com um arquivo .htaccess (Apache)?
Não há Apache, mas o NGINX está em execução dentro do container do Discourse. Este tópico pode ajudar:
Perfeito, obrigado @david 
Acabei de adicionar, mas agora cada imagem de https://cdn-uploads.example.com e https://cdn-origin.example.com exige a senha de autenticação. Existe uma maneira de proteger apenas https://discourse.example.com?
Caso contrário, agora recebo isso:
Não tenho certeza de como fazer isso exatamente, mas talvez alguém mais entre na conversa se tiver algumas ideias. Deve ser possível com alguns ajustes na configuração do nginx.
Como solução alternativa, e como se trata de um servidor de staging, você poderia simplesmente desativar o CDN? Se você usar o mesmo domínio para os ativos, eles receberão automaticamente o cabeçalho de autenticação, então você não precisará digitar a senha de autenticação novamente.
Sim, claro, se essa for a abordagem recomendada para um ambiente de staging, especialmente se você usa buckets S3 para backups e uploads, além do CloudFront como CDN para uploads e origem na produção.
Não é realmente necessário ter tudo isso para um ambiente de staging?
Essa alteração no nginx certamente não deve afetar os uploads para o S3 ou a CDN do S3. O NGINX não está envolvido nisso de forma alguma. Eu assumi que você estava usando uploads locais com uma CDN?
A situação ideal é fazer com que o site de staging seja configurado de forma idêntica ao site de produção.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-east-1
DISCOURSE_S3_ACCESS_KEY_ID: XXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_SECRET_ACCESS_KEY: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_CDN_URL: https://cdn-uploads.example.com
DISCOURSE_S3_BUCKET: example-uploads
DISCOURSE_S3_BACKUP_BUCKET: example-backup
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_CDN_URL: https://cdn-origin.example.com
E o domínio principal para staging é atualmente https://staging.example.com
Ainda assim, sou solicitado a autenticar em cada solicitação do cdn-origin com o código proposto ao acessar https://staging.example.com
Atualização para quem está enfrentando o mesmo problema:
Foi necessário liberar os cabeçalhos Authorization no CloudFront para o cdn-origin.
Parece que não fui solicitado a fornecer autenticação para o cdn-uploads.
Agora está funcionando.
Ativei a exigência de login no site de staging. Você pode fazer isso com uma variável de ambiente no app.yml para que seja persistente.
Não é bom o suficiente se o Google ou qualquer outra pessoa estiver encontrando o site. De qualquer forma, agora funciona.
Eles verão o site, mas não poderão ver nenhum conteúdo. Certo?
No nosso caso, precisamos ser capazes de ver como o site se comporta com usuários anônimos também. Tudo bem, funciona agora com basic_auth.
Bom, você me fez repensar como faço isso!
Olá @Terrapop,
Aqui está uma ideia para você e é assim que fazemos.
Se você executar seu ambiente de staging atrás do Apache2 (ou nginx) como um proxy reverso, poderá configurar regras de acesso no proxy reverso da mesma forma que faria com o .htaccess, como você está familiarizado.
Existem inúmeras vantagens em executar o Discourse atrás de um proxy reverso, e o controle de acesso facilitado é apenas um dos benefícios.
Espero que ajude.
Existe um guia infalível de como fazer para o Nginx? Estamos hospedando na DigitalOcean via Droplet e Docker.
Olá @Terrapop
Há muitos tutoriais excelentes no meta sobre como configurar o Discourse em uma configuração de “dois contêineres” atrás de um proxy reverso.
Você pode tentar pesquisar no meta:
two container reverse proxy
Espero que isso ajude.
Observe que, para fins de staging simples, muitas pessoas não configuram “dois contêineres” e fazem isso apenas em produção; mas, se você deseja fazer staging exatamente como em produção, então “dois contêineres” é certamente uma ótima opção. No entanto, você não precisa de “dois contêineres” para executar um aplicativo web atrás de um proxy reverso. Eu executo regularmente aplicativos web ROR e Docker atrás de um proxy reverso tanto em produção quanto em desenvolvimento.
Olá. Apenas gostaria de saber como você configurou corretamente o cabeçalho de autorização na whitelist no CloudFront? Adicionei “auth_basic” no app.yml conforme indicado acima. A proteção por senha está funcionando ao navegar pelo desktop, mas estou recebendo este erro ao navegar pelo mobile (após inserir usuário e senha):
Tenho isso no meu “cdn-origin”:
Política “whitelist-authorization-headers”:
Sou bastante novo no CloudFront e posso estar apenas ignorando algo muito óbvio (para a configuração mobile).