Sito spostato dietro proxy, favicon e intestazione non usano più HTTPS

Supporto
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

2

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

3

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

Yes it is.

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)

5

Ciao,
Vorrei tornare su questa questione. In realtà, ho lo stesso problema e non posso impostare force_https su true perché non c’è modo di accedere… (Errore sconosciuto all’accesso).
Come possiamo forzare il logo a essere referenziato con una richiesta https e non http?
Non dovrebbe essere semplice?
Grazie mille per il vostro riscontro (ho trascorso così tante ore dal mio lato per risolvere questo problema).

6

Dovrai invertire l’impostazione del sito force_https accedendo al server via SSH e avviando la riga di comando Ruby. Qui trovi argomenti howto su come farlo.

7

Grazie per la tua risposta. Ero certamente poco chiaro nel mio messaggio. In realtà, riesco a modificare force_https tramite il comando Rails senza problemi. Quindi, per essere più preciso:
Fino all’ultimo aggiornamento eseguito qualche giorno fa, che ha richiesto la ricompilazione del contenitore Docker, avevo una soluzione completamente funzionante con force_https impostato su true e applicando la seguente patch nella sezione server del file di configurazione di nginx per ottenere un accesso valido:

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

E funzionava. Tuttavia, dopo l’aggiornamento, la stessa patch non mi ha più permesso di accedere, restituendo il noto “Unknown error”.
Ho ottenuto la seguente traccia dal registro di produzione:

 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 che il nostro contenitore Discourse è in esecuzione su una VM accessibile tramite HTTPS.

Hai qualche idea sulla causa di questo cambiamento di comportamento prima e dopo l’aggiornamento?

Finora ho disabilitato force_https impostandolo su false; tutto funziona correttamente tranne il logo in alto a sinistra (logo del brand), che non viene visualizzato correttamente poiché viene richiamato tramite una richiesta http://…

A proposito, ecco l’URL del nostro sito: https://discourse.heig-vd.ch

8

Inoltre, ho anche trovato la seguente impostazione del sito che contiene l’URL colpevole:
SiteSetting.site_favicon_url (un’altra è SiteSetting.site_apple_touch_icon) con “http://…jpeg”.
Tuttavia, non sembra ovvio modificare il valore con un semplice comando rail, come facciamo ad esempio con force_https…

9

Qualche aiuto su questo argomento?

10

Puoi impostarli tramite la procedura guidata di configurazione. Esegui di nuovo la procedura guidata di configurazione e ricarica le immagini.

11

Ho impostato le immagini in quel modo. Ho rilanciato la procedura guidata, ma con lo stesso effetto alla fine :frowning:
Immagino che il caricamento delle immagini non influisca sul modo in cui vengono referenziate; è piuttosto una questione legata alla generazione della pagina web.

12

Bene, dopo così tanti tentativi falliti, ho finalmente capito come ottenere un login valido con force_https=true.

Nell’ambiente Docker, ho modificato /etc/nginx/conf.d/discourse.conf come segue:

…
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; <— Ciò che ho modificato
proxy_pass http://discourse;
}
…

E funziona solo in questa sezione, almeno nel mio ambiente.

Funziona benissimo ora!