Como relaxar a Política de Segurança de Conteúdo

Dev
1

Olá

Gostaria de fazer alguns testes no Discourse sem necessariamente passar pelo seu nome de domínio público configurado. Por exemplo, se o Discourse foi instalado e configurado como https://uat.mysite.com, então eu posso obviamente abrir meu navegador e acessar https://uat.mysite.com, o que significa que meu navegador sairia da minha rede interna para a Internet pública para resolver o nome de domínio para seu endereço IP público e carregar as páginas através de seu endereço IP público.

Acabei de tentar acessar o Discourse através do endereço IP interno do servidor (por exemplo, 192.168.1.2 mostrado abaixo) e, corretamente, ele não carrega devido à Política de Segurança de Conteúdo. Os erros que estou recebendo são da seguinte forma.

Refused to load the script 'http://192.168.1.2:12000/assets/locales/en-a9c88e45eb548bd7c807aecfd37d218891e213b5c1fd254857e0f16c72d73996.js' because it violates the following Content Security Policy directive: "script-src http://uat.mysite.com/logs/ http://uat.mysite.com/sidekiq/ http://uat.mysite.com/mini-profiler-resources/ http://uat.mysite.com/assets/ http://uat.mysite.com/brotli_asset/ http://uat.mysite.com/extra-locales/ http://uat.mysite.com/highlight_js/ http://uat.mysite.com/javascripts/ http://uat.mysite.com/plugins/ http://uat.mysite.com/theme-javascripts/ http://uat.mysite.com/svg-sprite/ 'sha256-rwfDVOTzygQmkOwFNAeX564B66beHoel4+gRLgQUgHg='". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

                                           ---------------------------------------------
                                          |                                             |
                                           ------------
uat.mysite.com resolve para 98.1.2.3 -->   |  IP Público |  Servidor executando Discourse.     |
                                          |  96.1.2.3.  |
                                           ------------                                 |
                                          |                                             |
                                          |                  ----------------           |
                                          |                  |  IP Privado  |           |
                                          |                  | 192.168.1.2  |           |
                                           ---------------------------------------------
                                                                         ^
                                                                         |
192.168.1.2   ------------------------------------------------------------

O motivo pelo qual eu gostaria de acessar o Discourse através do IP interno do servidor é porque quero fazer testes. Por exemplo, se eu quiser fazer testes de carregamento, não quero necessariamente carregar a rede que atende à Internet. Ou se eu quiser instalar uma instância de teste no meu laptop ou em um servidor de compilação sem necessariamente configurar o DNS.

Eu acho que sempre posso substituir isso definindo uma entrada personalizada em /etc/hosts, mas existe alguma maneira de desativar o CSP ou defini-lo para confiar em outras fontes para permitir testes?

1 curtida
2

Em seguida, configure sua máquina para resolver esse endereço para o IP local do servidor discourse. Existem muitas maneiras de fazer isso, mas elas dependem do sistema operacional, portanto, você deve incluir o sistema operacional em sua pesquisa no Google. (No Linux e acho que no Mac também, você pode simplesmente editar /etc/hosts.)

1 curtida
3

Eu, na verdade, tentei usar o /etc/hosts, mas ainda estou tendo o mesmo erro devido ao CSP. Eu pensaria que existe uma flag ou configuração que pode ser usada para alternar isso para permitir que os desenvolvedores façam tudo em seus laptops sem ter que configurar uma solução de DNS. Olhando para o Instalar Discourse no macOS para desenvolvimento - documentação / desenvolvedores - Discourse Meta, parece que ele inicializa algo que funciona com http://localhost:3000 em vez de um IP.

O desafio que tenho é que tenho automação para instalar o Discourse e quero usar o mesmo processo para configurar ambientes de desenvolvimento, UAT e produção, e não quero necessariamente que o ambiente de desenvolvimento seja acessível pela Internet pública, o que parece ser um requisito no momento, pois precisa resolver um FQDN adequado. Existem múltiplos casos de uso, um dos quais é, por exemplo, automatizar a atualização do Discourse no ambiente de desenvolvimento toda semana e executar uma série de testes para ver se algo quebra.

De qualquer forma, se houver uma maneira de relaxar o requisito para permitir o acesso direto via IP, seria bom saber. Caso contrário, acho que a única outra solução é configurar um pequeno serviço de DNS e, em seguida, apontar o laptop para usar o serviço de DNS personalizado, mas parece ser um pouco complicado.

4

Existe uma configuração de site chamada política de segurança de conteúdo. Você pode desmarcar e salvar para desabilitar o CSP.

Desde que isso não seja feito em uma instância de produção, está tudo bem.

3 curtidas
5

Essa não é uma boa ideia. Nunca vai funcionar. Um ambiente de desenvolvimento é desnecessariamente diferente, pois tem ativos pré-compilados e um monte de outras coisas que tornam o desenvolvimento impossível. A menos que você esteja desenvolvendo plugins, você não precisa de um ambiente de desenvolvimento. Portanto, se for esse o caso, seu ambiente de desenvolvimento pode ser uma instalação docker, apenas não é o que seria chamado de ambiente de desenvolvimento aqui.

Você quer lançar seus ambientes de staging e produção usando docker, conforme descrito na instalação padrão.

3 curtidas
6

Olá! Eu faço isso regularmente, mas com instalações Docker. Assumindo que você usa nossa instalação Docker padrão em produção, então para seus testes de aceitação você deve usar a mesma coisa. Existe uma grande margem para diferenças entre instalações de desenvolvimento e Docker (configuração, versões de pacotes de gem e JS, etc.) que podem se tornar dores de cabeça no momento da implantação.

As instalações Docker usam e aplicam HTTPS por padrão. A menos que você queira personalizar o template do container (o que descobri que tem alguma complexidade oculta), você pode simplesmente desativar a aplicação de HTTPS com outra configuração do site.

Este é o meu trecho para “relaxar a segurança em uma instalação Docker local”, que pode ser facilmente revertido antes de ir para produção:

SiteSetting.content_security_policy = false
SiteSetting.force_https = false

Então, é apenas uma questão de o seu navegador ser capaz de encontrar a porta 80 no container Docker em http://uat.mysite.com – note que você estará usando http em vez de https.

Para isso, o truque de /etc/hosts do @pfaffman é o caminho; detalhes para cada sistema operacional aqui.

2 curtidas