Site movido atrás de proxy; favicon e cabeçalho não estão mais usando HTTPS

Suporte
1

Desde então, movi minha instância do Discourse entre servidores, e agora ela está rodando atrás de um proxy reverso com terminação SSL.

No entanto, a imagem de cabeçalho e o favicon não estão sendo solicitados via HTTPS e estão sendo bloqueados. Tentei ativar a opção “forçar HTTPS”, mas isso não ajudou.

image

2

Seu proxy está fornecendo um cabeçalho X-Forwarded-Proto? (Deveria).

3

Seu proxy está fornecendo um cabeçalho X-Forwarded-Proto? (Deveria estar).

Sim, está.

4

Eu tive o mesmo problema. Tenho uma instância do Discourse atrás do HAProxy com terminação SSL. A correção é bem simples, mas não é óbvia:

  1. Primeiro, certifique-se de que a opção “forçar https” está ativada nas configurações (vá em Configurações e filtre por “forçar https”).
  2. Vá em Configurações > Branding > e simplesmente faça o upload novamente dos seus logotipos.
  3. Agora tudo deve usar HTTPS (certifique-se de clicar no botão de atualizar do navegador).

(Acho que isso pode ser um bug no Discourse)

5

Olá,
Gostaria de retomar essa questão. Na verdade, estou com o mesmo problema e não consigo definir force_https para true, pois não há como fazer login… (Erro desconhecido no login).
Como podemos forçar que o logo seja referenciado com uma requisição HTTPS e não HTTP?
Não deveria ser fácil?
Muito obrigado pelo retorno (tantas e tantas horas gastas do meu lado tentando corrigir isso).

6

Você precisará alterar a configuração do site force_https acessando o servidor via SSH e entrando na linha de comando Ruby. Há tópicos de howto sobre como fazer isso aqui.

7

Obrigado pela sua resposta. Certamente fui pouco claro na minha mensagem. Na verdade, consigo alterar o force_https usando o comando do Rails sem problemas. Então, para ser mais claro:

Até a última atualização que realizei há alguns dias, que exigiu a reconstrução do contêiner Docker, eu tinha uma solução totalmente funcional com o force_https definido como true e com o seguinte patch que precisei aplicar na seção server do arquivo de configuração do nginx para obter um login válido:

  if ($http_x_forwarded_proto = 'http'){
    return 301 https://$host$request_uri;
  }

E funcionava. No entanto, desde a atualização, o mesmo patch não me permitiu fazer login novamente, apresentando o conhecido “Unknown error”.

Obtive o seguinte rastreamento do log de produção:

 Started POST "/session" for 193.134.222.4 at 2020-05-14 19:24:40 +0000
 Processing by SessionController#create as */*
 Parameters: {"login"=>"rossierd", "password"=>"[FILTERED]", "second_factor_method"=>"1", "timezone"=>"Europe/Zurich"}
 Can't verify CSRF token authenticity.
 Rendering text template
 Rendered text template (Duration: 0.0ms | Allocations: 1)
 Filter chain halted as :verify_authenticity_token rendered or redirected
 Completed 403 Forbidden in 2ms (Views: 0.7ms | ActiveRecord: 0.0ms | Allocations: 1101)

Considerando que temos nosso contêiner Discourse rodando em uma máquina virtual acessível via HTTPS.

Você tem alguma ideia sobre a causa dessa mudança de comportamento antes e depois da atualização?

Até agora, desativei o force_https para false; tudo funciona bem, exceto o logotipo no canto superior esquerdo (logotipo da marca), que não aparece corretamente, pois é referenciado por meio de uma solicitação http://…

Aliás, aqui está a URL do nosso site: https://discourse.heig-vd.ch

8

Além disso, também encontrei a seguinte configuração do site que contém a URL culpada:
SiteSetting.site_favicon_url (outro é SiteSetting.site_apple_touch_icon) com “http://…jpeg”.
No entanto, parece não ser óbvio alterar o valor com um simples comando do Rails, como fazemos com force_https, por exemplo)…

9

Por favor, alguma ajuda sobre este tópico?

10

Você os definiu por meio do assistente de configuração. Execute o assistente de configuração novamente e faça o upload das imagens novamente.

11

Configurei as imagens dessa forma. Reiniciei o assistente, mas com o mesmo resultado no final :frowning:
Acho que o upload das imagens não afeta a forma como elas são referenciadas; isso está mais relacionado à geração da página web.

12

Bem, depois de tantas tentativas malsucedidas, finalmente descobri como fazer um login válido com force_https=true.

No ambiente Docker, modifiquei o arquivo /etc/nginx/conf.d/discourse.conf da seguinte forma:

…
location @discourse {
limit_conn connperip 20;
limit_req zone=flood burst=12 nodelay;
limit_req zone=bot burst=100 nodelay;
proxy_set_header Host $http_host;
proxy_set_header X-Request-Start “t=${msec}”;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https; # $thescheme; ← O que eu modifiquei
proxy_pass http://discourse;
}
…

E isso apenas funciona nesta seção, pelo menos no meu ambiente.

Agora funciona perfeitamente!