Mit Discourse-Benutzern an einer SPA arbeiten

Ich versuche, eine Möglichkeit zu finden, benutzerspezifische Daten in einer SPA von Discourse abzurufen.

Grobe Einrichtung
SPA läuft unter my-app.com
Discourse läuft unter community.my-app.com

Die SPA hat keine eigene Benutzerverwaltung. Ich möchte Discourse dafür verwenden (da wir keine anderen benutzerspezifischen Dinge haben, die eine eigene Benutzerverwaltung benötigen würden).

Aber ich möchte den aktuell angemeldeten Benutzer von Discourse in der SPA anzeigen, sowie ein Widget mit den ungelesenen Themen (die benutzerspezifisch sind) anzeigen, zum Beispiel, daher muss ich Daten per API von Discourse laden.

Versuchte Dinge:

  • Den Discourse SSO-Pfad verwenden, der dann zurück zu meiner SPA umleitet. Das ist in Ordnung, ich erhalte die E-Mail-Adresse des aktuellen Benutzers, die externe ID und so weiter – aber nichts, womit ich anfragen könnte (Token / Schlüssel).
  • Mit Cookie-Einstellungen spielen, um das Discourse-Cookie verwenden zu können, um die Anfrage zu stellen (kein Erfolg).
  • Ich habe von den User API Keys unter User API keys specification gelesen, aber es wäre mir seltsam, wenn der Benutzer einer App, die dieselbe Seite ist, den Zugriff auf sein Discourse-Konto erlaubt.

Gibt es eine Möglichkeit, das gewünschte Verhalten zu erreichen?

Grüße
Marcel

1 „Gefällt mir“

Würde das funktionieren?

  1. Verwenden Sie DiscourseConnect („Discourse SSO“) wie beschrieben, um den Benutzernamen des aktuellen Benutzers zu erhalten.
  2. Erstellen Sie einen API-Schlüssel mit den benötigten Bereichen und Zugriff auf „alle Benutzer“.
  3. Offensichtlich können Sie diesen Schlüssel nicht an die Webanwendung auf der Client-Seite weitergeben, ohne die Website zu gefährden. Daher müssen Sie Anfragen von der Webanwendung über das Backend dieser Anwendung an Ihre Discourse-Instanz weiterleiten. (Und Sie müssten vom Backend aus überprüfen, ob der Benutzername legitim ist – ich habe mir DiscourseConnect noch nicht angesehen, aber vermutlich gibt es dafür eine Möglichkeit.)

(PS: Ich empfehle die Verwendung von „example.com“ für Ihre Beispiel-Domain. Jemand könnte die von Ihnen verlinkte kaufen und Spam, Malware oder Ähnliches einrichten, während example.[com|org|net] offiziell reserviert sind.)

1 „Gefällt mir“

Ja, das ist tatsächlich die Methode, die ich jetzt verwende.

Der Benutzer wird durch SSO geschickt, die Middleware erstellt einen einfachen Benutzer mit Namen, E-Mail und einem Token-Array, erstellt einen Token und gibt ihn an die SPA zurück.

Die Middleware leitet die Anfragen mit einem API-Schlüssel für alle Benutzer an Discourse weiter und validiert den „Sitzungstoken“ (um zu sehen, welcher Benutzer es ist) und einige andere Sicherheitsmechanismen.

Damit der Benutzer eingeloggt bleibt, werde ich einen Cookie / lokalen Speicher verwenden und die Abmeldung über die direkte Abmeldeoption von Discourse synchronisieren.

Es funktioniert, aber ich glaube immer noch, dass es eine bessere Option geben sollte, als mit einem Admin-API-Token in Kombination mit einem Benutzernamen zu arbeiten. Es bricht, wenn ein Administrator den Benutzernamen von jemandem ändert… Ich hätte gerne eine Hash-ID oder so etwas… Aber nichts, was ich ändern kann, also werde ich damit leben :wink:

Danke für deine Antwort.

2 „Gefällt mir“