Google-Authentifizierungsfehler

Unterstützung
1

Hallo,

ich bin neu bei Discourse. Ich habe kürzlich ein Forum erstellt und bin gerade dabei, die Website und das Forum auf eine neue Domain zu verlegen.

Die alte Domain des Forums: https://forum.skymail.app (nicht aktiv, leitet auf die neue Website weiter)

Neue Domain: https://forum.sugarmail.app (betriebsbereit)

Ich habe Probleme mit der Google-Authentifizierung. Ich habe ein Google Cloud-Projekt, und nachdem ich auf die neue Domain umgestellt habe, habe ich dort auch die Redirect-URL unter Client ID geändert. Aktuell ist sie auf

https://forum.sugarmail.app/auth/google_oauth2/callback

eingestellt.

Nun zum Problem: Beim Versuch, sich mit Google anzumelden, erhalte ich in Discourse diese Fehlermeldung:

https://forum.sugarmail.app/auth/failure?message=csrf_detected Die Autorisierung ist abgelaufen, oder Sie haben den Browser gewechselt. Bitte versuchen Sie es erneut.

Als das Forum noch unter der alten Domain forum.skymail.app lief, funktionierte die Google-Authentifizierung problemlos.

Ich habe nach der Änderung der Domain ./launcher rebuild app ausgeführt und dabei sichergestellt, dass die Domain in app.yaml unter DISCOURSE_HOSTNAME aktualisiert wurde (tatsächlich ließ sich das Forum gar nicht laden, bis ich das getan hatte).

Haben Sie irgendwelche Tipps?

2

Normalerweise wird beim Start des Login-Prozesses der Cookie _forum_session in Ihrem Browser gesetzt. Auf Ihrer Seite scheint dies jedoch nicht zu erfolgen.

Haben Sie Plugins oder Proxies, die die Cookies auf Ihrer Seite beeinträchtigen könnten?

3

Vielen Dank für die Antwort.

Plugins – nein, ich verwende keine. Das Einzige, was ich nach der Installation getan habe, war die Aktivierung von Google Auth (Client-ID und Geheimnis) sowie die Aktivierung von “Immer HTTPS verwenden”.

Proxies – Ich verwende nginx als Reverse-Proxy (der auch die Haupt-App-Site bedient).

    # discourse
    location / {
            proxy_set_header X-Real-IP $remote_addr;
            proxy_pass_request_headers on;
            proxy_pass http://localhost:10080;
    }

und in containers/app.yaml:

expose:
  - "10080:80"   # http
  - "10443:443" # https

Let’s Encrypt ist in den Discourse-Einstellungen nicht aktiviert. Der nginx innerhalb des Containers bedient also reines HTTP, während der externe nginx die SSL-Terminierung übernimmt.

Das ist fast dieselbe Konfiguration wie bei der alten Domain, der einzige Unterschied ist “HTTPS erzwingen”.

Ich verwende Version 2.6.0.beta3.

4

Ach du Schreck, es heißt “HTTPS erzwingen”, was ich zuvor deaktiviert hatte.

Ich habe es kürzlich aktiviert, um die Warnung in Chrome bezüglich “unsicherer Seiteninhalte” zu vermeiden, die aufgrund von reinen HTTP-Links zu Bildern auftrat.

Zur Wiederholung: Ich führe die SSL-Terminierung im “externen” Nginx durch, und was Discourse selbst betrifft, gibt es kein SSL.

Das Deaktivieren von “HTTPS erzwingen” lässt die Google-Authentifizierung wieder funktionieren (ich musste eine einfache HTTP-Weiterleitungs-URL im Google Cloud-Projekt hinzufügen).

Das ist jedoch nicht ideal, da es zu Warnungen bezüglich “unsicherer Seite” bzw. gemischter Inhalte kommt, sobald Bilder vorhanden sind.

Gibt es eine Möglichkeit, die Google-Authentifizierung mit aktivierter Option “HTTPS erzwingen” und einer SSL-Terminierung außerhalb von Discourse funktionsfähig zu halten?

(Ich würde die eigene SSL-Unterstützung von Discourse nutzen, aber diese geht davon aus, dass sie die Domain “besitzt”, sodass ich eine zusätzliche IP-Adresse für diesen VPS einrichten und die Hauptseite vom Forum trennen müsste … was etwas aufwendig ist … )

5

Stellen Sie sicher, dass Sie X-Forwarded-Proto: https mitsenden.

6

Vielen Dank, @riking! Ich habe den nginx-Block aus deinem Link wortwörtlich übernommen und dann die Option „HTTPS erzwingen

7

Ah, egal. Ich habe gerade ein neues, benutzerdefiniertes Favicon festgelegt, und es wird nun über HTTPS abgerufen. Keine “mixed content”-Warnungen mehr.

Wunderschön, danke für deine Hilfe!