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