Discourse ID schlägt fehl, auf meiner Instanz zu aktivieren

SSO
,
21

Würde proxy_set_header X-Forwarded-Proto https; funktionieren?

22

Die http/s-Anfrage kommt vom Container an den IDP-Server für Discourse ID im Internet. Es gibt keine Instanz dazwischen, wo ich Anforderungsheader hinzufügen/ändern könnte.

Meiner Meinung nach und unter der Annahme, dass „Discourse ID“ nur Standard-OAuth ist, wäre der richtige Weg entweder
a) eine Konfigurationsoption für Discourse ID, bei der ich einen „bekannten“ Konfigurationsendpunkt hinzufügen könnte, der alle erforderlichen OIDC-Konfigurationswerte enthält, einschließlich des „https://… Präfixes.
b) dasselbe, aber bereits in den Code einprogrammiert.

Ich grüble noch über die technischen Details von Discourse ID …

23

Sie können die Details der Discourse-ID in unserem Code nachschlagen, das von uns verwendete Protokoll ist in unserem Github-Repository vollständig dokumentiert. Der einzige Unterschied zu anderen OAuth-Implementierungen besteht darin, dass wir eine Instanz automatisch registrieren. Und während dieser automatischen Registrierung stellen wir sicher, dass die Instanz, die sich registrieren möchte, diejenige ist, für die sie sich ausgibt, und dass sie über https verfügt (in der heutigen Zeit sollte keine Discourse-Instanz über http:// laufen).
Die http-Fehler, die ich oben geteilt habe, sagen mir, dass Ihre Website nicht richtig konfiguriert ist.
Können Sie die Ausgabe der folgenden Befehle über die Konsole überprüfen:

Discourse.base_url

SiteSetting.force_https

Wenn Sie vom ersten Befehl eine http://-URL und vom zweiten false erhalten, möchten Sie vielleicht SiteSetting.force_https = true setzen und sehen, ob das Problem behoben wird. (Es könnte jedoch auch Dinge kaputt machen, wenn die Konfiguration an anderer Stelle falsch ist. Seien Sie vorsichtig.)

1 „Gefällt mir“
24

Hallo Penar,
vielleicht müssen wir zuerst die Details meines Setups klären. Es unterscheidet sich etwas von der Standardbereitstellung.

  • zentraler Load Balancer (https://www.haproxy.org/) fungiert als SSL-Beschleuniger für verschiedene Webdienste (nicht nur für Discourse). Der Zugriff aus dem Internet auf einen dieser Dienste ist nur über HTTPS gestattet. Der Wechsel von HTTP zu HTTPS erfolgt auf dem Load Balancer selbst, siehe Redirect HTTP to HTTPS in a Few Easy Steps with HAProxy als Referenz)
  • HAProxy leitet Frontend-Anfragen an das Backend in einem privaten Netzwerk (10.x.x.x) ohne Verschlüsselung weiter. Dieser Datenverkehr endet bei einem lokalen Nginx auf dem Docker-Host.
  • Nginx leitet Anfragen mit proxy_pass ``http://unix``:/mnt/data/discourse/shared/web-only/nginx.http.sock an den HTTP-Socket des web_only-Containers weiter.
    (Ich verwende ein Zwei-Container-Setup mit web_only.yml und data.yml). Siehe templates/web.socketed.template.yml als Referenz.

Ich benötige SiteSetting.force_https nicht, da die gesamte HTTPS-Verschlüsselung außerhalb des Discourse-Containers erfolgt. Ich verwende bereits OAuth basierend auf dem Plugin Discourse OpenID Connect (OIDC) und mit meinem eigenen IDP. Das Discourse OIDC-Plugin enthält eine Einstellung für das „well-known“ OpenID Connect discovery document. In meinem Fall: https://login.netzwissen.de/realms/netzwissen/.well-known/openid-configuration

Wenn Discourse ID etwas Ähnliches für die Verbindung zwischen der Discourse-Container-Instanz und dem Discourse ID IDP implementieren würde, gäbe es keine Probleme. Da „Discourse ID“ einen festen IDP verwendet, könnte eine solche „Well-Known-URL“ sogar fest kodiert werden, einschließlich des HTTPS-Präfixes.

25

Thomas, tut mir leid, ich kann dir bei deinem spezifischen Setup nicht wirklich helfen. Alles, was ich sagen kann, ist, dass etwas in deiner Instanz falsch ist.

Nun, die JS-Konsole auf deiner Website glaubt nicht, dass die HTTPS-Verschlüsselung außerhalb des Containers alles abdeckt. Diese JS-Warnungen, die ich oben geteilt habe, sind Symptome eines ähnlichen Problems, das du mit ID hast. Discourse selbst in deinem Setup denkt, dass es in http läuft, und das ist ein Problem, da es in einigen Fällen URLs in http generieren wird.

2 „Gefällt mir“
26

Penar, es tut mir sehr, sehr leid:

Ich habe die Einstellungen unserer produktiven Instanz (PROD) mit denen der DEV-Instanz verglichen. Nur in der DEV-Instanz war die Einstellung force_https deaktiviert. Und das funktionierte nur, weil wir den SSL-Haproxy-SSL-Beschleuniger davor geschaltet haben.

Ich habe jetzt SiteSetting.force_http in der DEV-Instanz aktiviert und Discourse ID funktioniert einwandfrei. Daher werde ich Discourse ID auch auf unserer PROD-Instanz (forum.netzwissen.de) bereitstellen.

Entschuldigung für die Verwirrung.

3 „Gefällt mir“
27

Keine Sorge, ich freue mich, dass es geklärt ist. Danke für die Nachverfolgung!

2 „Gefällt mir“