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

Supporto
1

Da allora ho spostato la mia istanza di Discourse tra server diversi ed ora è in esecuzione dietro un reverse proxy con terminazione SSL.

Tuttavia, l’immagine dell’intestazione e il favicon non vengono richiesti tramite HTTPS e vengono bloccati. Ho provato ad attivare “force https”, ma questo non ha risolto il problema.

image

2

Il tuo proxy sta fornendo un’intestazione X-Forwarded-Proto? (Dovrebbe farlo).

3

Il tuo proxy sta fornendo un header X-Forwarded-Proto? (Dovrebbe farlo).

Sì, lo fa.

4

Ho avuto lo stesso problema. Ho un’istanza di Discourse dietro HAProxy con terminazione SSL. La soluzione è piuttosto semplice, anche se non immediata:

  1. Innanzitutto, assicurati che l’opzione “forza https” sia abilitata nelle impostazioni (vai su Impostazioni e filtra per “force https”).
  2. Vai su Impostazioni > Branding e ricarica semplicemente i tuoi loghi.
  3. Ora tutto dovrebbe utilizzare HTTPS (assicurati di premere il pulsante di aggiornamento del browser).

(Credo che possa trattarsi di un 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!