Ela está desligada. X-Forwarded-Proto está no meu bloco de servidor. Portanto, o único elemento(s) que não estou utilizando — com base nos links que todos vocês compartilharam — é este:
# modelos base utilizados; pode reduzir para incluir menos funcionalidade por modelos de container: # - "templates/cron.template.yml" # cron agora está incluído na imagem base - "templates/postgres.template.yml" - "templates/redis.template.yml" - "templates/sshd.template.yml" - "templates/web.template.yml" # - "templates/web.ssl.template.yml" # remover - https será tratado pelo nginx externo - "templates/web.ratelimited.template.yml" - "templates/web.socketed.template.yml" # <-- Adicionado # quais portas expor? # expose: comente toda a seção
Carreguei o site em 3 navegadores (Edge, Firefox e Chrome Mobile) e recebi um certificado perfeitamente válido como anônimo. Quais são os seus passos para reproduzir isso?
O inferno não se soltou aqui. Um problema potencial é que seus e-mails ainda contêm o link http://. No entanto, fui redirecionado corretamente para o site HTTPS para ativar minha conta e não vejo nenhum erro relacionado ao SSL aqui.
É aí que você está errado. Se o “force https” estiver habilitado, o Discourse deve enviar todos os links como https. Cada link relacionado ao fórum deve ser carregado via https. Se você ainda está fazendo coisas estranhas e não seguindo o método sugerido, está por conta própria. Não podemos ajudar além dos procedimentos padrão que funcionam.
Isso não faz muito sentido para mim. Se analisarmos logicamente, estou essencialmente fazendo exatamente o que o force-https é destinado a fazer, mas dentro do bloco do servidor.
force_https não é apenas uma reescrita. Ele faz mais do que isso internamente. Se você deseja que seus problemas sejam resolvidos, uma solução já foi fornecida. Se você rejeitar a solução, sinta-se à vontade para assumir as próprias responsabilidades e explorar novas alternativas.
Isso ocorre por causa do seu proxy reverso instável. Você terá que descobrir o que está errado e fazer as coisas da maneira correta. Não podemos fornecer assistência com suas próprias soluções.
Todas as “soluções” apresentadas não se encaixam no meu caso de uso específico:
Servidor remoto (na mesma rede) — Acredito que todos os exemplos assumem que o Nginx está rodando no mesmo servidor que o Discourse. Estou usando proxy_pass para acessar outro IP interno.
Por que fiz isso? Maior segurança e dispersão de recursos. É a mesma razão pela qual dividi os serviços de duas formas: por container e por VM. A documentação sugerida parece favorecer um cenário em que todos os serviços estão rodando no mesmo servidor.
Imagino que as condições descritas acima sejam bastante comuns. Se alguma delas puder ser usada para acomodar uma configuração de proxy_pass, ficarei mais do que feliz em ajustar minhas configurações conforme necessário. Apenas sinto que fornecer uma declaração genérica do tipo “você está por sua conta” porque estou tentando evitar o cenário de “colocar todos os ovos na mesma cesta” é um pouco injustificado.
Essa é a sua preferência; eu escrevi como um exemplo. Você também pode optar por expor a porta 80.
Não há benefício ou sentido em ativar o SSL em uma rede local.
Isso precisa existir.
server {
listen 80;
server_name discourse.example.com;
return 301 https://example.com$request_uri;
}
É exatamente isso que está acontecendo. Você está encaminhando todas as requisições recebidas pelo seu proxy/ingress para um backend interno na porta 8080 (ou seja, o Discourse).
Respondido no ponto #1: foi uma preferência pessoal. Sinta-se à vontade para usar a porta que preferir.
Você especialmente não precisa de nada relacionado a sockets ou SSL no servidor interno. O SSL deve ser adequadamente terminado no proxy reverso.
Nota: a maior parte disso é uma preferência pessoal baseada na implantação para clientes.
O comportamento que estou experimentando ocorre sob as condições acima.
O início do app.yml se parece com isto:
## este é o modelo de contêiner Docker Discourse tudo-em-um, autônomo ## ## Após fazer alterações neste arquivo, você DEVE reconstruir ## /var/discourse/launcher rebuild app ## ## TENHA *MUITO* CUIDADO AO EDITAR! ## ARQUIVOS YAML SÃO SUPER SUPER SENSÍVEIS A ERROS EM ESPAÇOS EM BRANCO OU ALINHAMENTO! ## visite http://www.yamllint.com/ para validar este arquivo conforme necessário
templates: - "templates/postgres.template.yml" - "templates/redis.template.yml" - "templates/web.template.yml" - "templates/web.ratelimited.template.yml" ## Descomente estas duas linhas se desejar adicionar Lets Encrypt (https) #- "templates/web.ssl.template.yml" #- "templates/web.letsencrypt.ssl.template.yml"
## quais portas TCP/IP este contêiner deve expor? ## Se você quiser que o Discourse compartilhe uma porta com outro servidor web como Apache ou nginx, ## consulte https://meta.discourse.org/t/17247 para detalhes expose: - "80:80" # http - "443:443" # https
## Defina db_shared_buffers para no máximo 25% da memória total. ## será definido automaticamente pelo bootstrap com base na RAM detectada, ou você pode substituir db_shared_buffers: "1024MB"
## pode melhorar o desempenho de classificação, mas aumenta o uso de memória por conexão #db_work_mem: "40MB"
## Qual revisão do Git este contêiner deve usar? (padrão: tests-passed) #version: tests-passed
Você está se conectando à porta 80 no segundo nginx, então ele acha que você está se conectando via HTTP e não HTTPS.
Tente encontrar o X-Forwarded-Proto no nginx interno e altere proxy_set_header X-Forwarded-Proto $thescheme; para proxy_set_header X-Forwarded-Proto https;
ou encaminhe seu tráfego para HTTPS proxy_pass https://192.168.86.108