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

Suporte
1

I’ve since moved my Discourse instance between servers, and is now running behind a reverse proxy with SSL termination.

However, the header image and favicon are not being requested over HTTPS and getting blocked. I tried setting “force https” to on, but this hasn’t helped.

image
image.png1907×60 8.92 KB

1 curtida
2

Is your proxy supplying an X-Forwarded-Proto header? (It should).

3 curtidas
3

Is your proxy supplying an X-Forwarded-Proto header? (It should).

Yes it is.

1 curtida
4

I had the same issue. I have a Discourse instance behind HAProxy with SSL termination. The fix is pretty simple, but not obvious:

  1. First make sure that “force https” is enabled in the settings (go to Settings and filter by “force https”).
  2. Go to Settings > Branding > and just re-upload your logos.
  3. Everything should use HTTPS now (be sure to hit your browser refresh button).

(I think this may be a bug in Discourse)

3 curtidas
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.

1 curtida
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!

1 curtida