Ändern von force_https aktualisiert die URL von hochgeladenen Bildern nicht und verursacht eine Mixed-Content-Warnung

[JanKanis]

Ich habe soeben force_https in meiner Discourse-Installation aktiviert. Die HTTPS-Terminierung wird von einem Reverse-Proxy davor übernommen. Durch das Aktivieren von force_https werden die meisten internen Links von Discourse auf https umgestellt, jedoch nicht diejenigen für bereits vorhandene Bilder, insbesondere Favicons und das Logo. Wenn ich meine Website nun über https aufrufe, erscheint eine Warnung wegen gemischter Inhalte, da nicht-verschlüsselte Bilder eingebunden werden.

Die Links können durch erneutes Hochladen der Bilder oder durch Ausführen von SiteIconManager.ensure_optimized! in der Rails-Konsole auf https umgestellt werden. Offensichtlich wird der Link irgendwo zwischengespeichert und nicht aktualisiert, wenn force_https geändert wird.

Discourse sollte die Links zu hochgeladenen Bildern (und wahrscheinlich zu allen Uploads) aktualisieren, wenn force_https umgeschaltet wird. Noch besser wäre es, wenn in diesen Links das Schema gar nicht enthalten wäre, obwohl ich nicht weiß, ob das möglich ist.

[pfaffman (Jay Pfaffman)]

Wie hast du installiert? Force_https ist schon seit geraumer Zeit standardmäßig aktiviert.

[JanKanis]

Ich erstelle Docker-Images (aufgeteilt in web_only und data) mit dem discourse_docker-Repository und führe die Images in einer Kubernetes-Cloud hinter einem Proxy aus, der die HTTPS-Terminierung übernimmt. Der Discourse-Container lauscht nur auf Port 80, und ich habe die SSL- und Let’s Encrypt-Vorlagen in der Container-Konfigurationsdatei nicht aktiviert. Offenbar ist es die Let’s Encrypt-Vorlage, die force_https auf true setzt, sodass sie für mein Setup standardmäßig nicht aktiviert war.

[RGJ (Richard - Communiteq)]

@pfaffman

ist standardmäßig aktiviert

Nicht ganz, es wird bei der Bereitstellung aktiviert, aber die Standardeinstellung der Site ist false.

config/site_settings.yml

Ich habe auch gesehen, wie Leute die Site-Einstellung deaktiviert haben, während sie Probleme behoben haben, weil sie als „geänderte

[riking (Kane York)]

@JanKanis

Ich führe die Images in einer Kubernetes-Cloud hinter einem Proxy aus, der die HTTPS-Terminierung übernimmt.

Stellen Sie sicher, dass Ihr Proxy alle erforderlichen Header sendet, die in den nginx-Konfigurationen hier festgelegt sind:

Run other websites on the same machine as Discourse

@pfaffman edited this heavily 2022.02.24. Blame me if it’s broken. If you want to run other websites on the same machine as Discourse, you need to set up an extra NGINX or HAProxy proxy in front of the Docker container. NOTE: This is for advanced admins This guide assumes you already have Discourse working - if you don’t, it may be hard to tell whether or not the configuration is working. You cannot use ./discourse-setup to set up Discourse if another server is using port 80 or 443. You will…

Insbesondere wird X-Forwarded-Proto standardmäßig oft nicht enthalten.

[RGJ (Richard - Communiteq)]

Dies ist ein Problem, selbst wenn der Proxy den X-Forwarded-Proto-Header und weitere Header sendet.

Das Umschalten der Site-Einstellung force_https aktualisiert das Logo-URL-Protokoll erst, nachdem der icon_manager-Cache geleert wurde. Das Hinzufügen von force_https zu den beobachteten Einstellungen für den Icon-Manager ist wahrscheinlich die einfachste Lösung.

[pfaffman (Jay Pfaffman)]

@RGJ

Nicht ganz, es wird bei der Bereitstellung aktiviert, aber die Standardeinstellung für die Site ist false.

Richtig! Bei einer Standardinstallation wird dies automatisch festgelegt, weshalb ich vermutete, dass es sich hier nicht um eine Standardinstallation handelt.

Ich bin mir ziemlich sicher, dass auf der GKE-Site, die ich verwalte, dies über die Umgebungsvariable DISCOURSE_FORCE_HTTPS eingestellt ist und wie erwartet funktioniert. Da ich dies jedoch schon vor langer Zeit eingerichtet habe, könnte ich etwas vergessen haben.

[irwinstar]

Ich habe diese „Force HTTPS“-Einstellung geprüft und sie erneut aktiviert. Das hat bei mir funktioniert.