Site hinter Proxy verschoben, Favicon und Header verwenden HTTPS nicht mehr

Unterstützung
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

Hallo,
ich möchte gerne auf dieses Problem zurückkommen. Tatsächlich habe ich das gleiche Problem, und ich kann force_https nicht auf true setzen, da es keine Möglichkeit gibt, sich einzuloggen… (Unbekannter Fehler beim Login).
Wie können wir erzwingen, dass das Logo mit einer HTTPS-Anfrage und nicht mit HTTP referenziert wird?
Sollte das nicht einfach sein?
Vielen Dank für Ihr Feedback (ich habe so viele, viele Stunden auf meiner Seite verbracht, um dies zu beheben).

6

Sie müssen die Site-Einstellung force_https ändern, indem Sie sich per SSH mit dem Server verbinden und die Ruby-Kommandozeile aufrufen. Hier finden Sie #howto-Themen dazu.

7

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

8

Zusätzlich habe ich die folgende Site-Einstellung gefunden, die die schuldige URL enthält:
SiteSetting.site_favicon_url (eine weitere ist SiteSetting.site_apple_touch_icon) mit „http://…jpeg".
Es scheint jedoch nicht offensichtlich, den Wert mit einem einfachen Rails-Befehl zu ändern, wie wir es beispielsweise bei force_https tun.

9

Haben Sie irgendwelche Hilfe zu diesem Thema?

10

Sie haben diese über den Einrichtungsassistenten festgelegt. Führen Sie den Einrichtungsassistenten erneut aus und laden Sie die Bilder erneut hoch.

11

Ich habe die Bilder so eingestellt. Ich habe den Assistenten erneut gestartet, aber am Ende das gleiche Ergebnis: :frowning:
Ich vermute, das Hochladen der Bilder hat keinen Einfluss darauf, wie sie referenziert werden; es hängt eher mit der Generierung der Webseite zusammen.

12

Nun, nach so vielen erfolglosen Versuchen habe ich endlich herausgefunden, wie man mit force_https=true eine gültige Anmeldung erreicht.

In der Docker-Umgebung habe ich /etc/nginx/conf.d/discourse.conf wie folgt gepatcht:

…
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; ← Das habe ich geändert
proxy_pass http://discourse;
}
…

Und es funktioniert nur in diesem Abschnitt, zumindest in meiner Umgebung.

Funktioniert jetzt großartig!