Danke für deine Antwort. Ich war in meiner Nachricht sicherlich unklar. Tatsächlich kann ich force_https problemlos über den Rails-Befehl ändern. Also, um es klarer zu sagen:
Bis zum letzten Upgrade, das ich vor ein paar Tagen durchgeführt habe und das einen Neuaufbau des Docker-Containers erforderte, hatte ich eine vollständig funktionierende Lösung mit force_https auf true und dem folgenden Patch, den ich im Server-Abschnitt der nginx-Konfigurationsdatei anwenden musste, um eine gültige Anmeldung zu erhalten:
if ($http_x_forwarded_proto = 'http'){
return 301 https://$host$request_uri;
}
Das hat funktioniert. Seit dem Upgrade jedoch erlaubt derselbe Patch keine Anmeldung mehr, und es erscheint der bekannte „Unbekannter Fehler".
Ich habe folgenden Trace aus dem Produktionslog erhalten:
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)
Unser Discourse-Container läuft in einer VM, die über HTTPS erreichbar ist.
Hast du eine Idee, was die Ursache für dieses veränderte Verhalten vor und nach dem Upgrade sein könnte?
Bisher habe ich force_https auf false gesetzt. Alles läuft gut, außer das Logo oben links (Markenlogo), das nicht korrekt angezeigt wird, da es über eine http://-Anfrage referenziert wird…
Übrigens, hier ist die URL unserer Seite: https://discourse.heig-vd.ch