Hallo, ich möchte mich nach user_api_keys erkundigen. Derzeit arbeite ich daran, unsere App für die Autorisierung mit Discourse user_api_keys zu integrieren. Meine Frage ist: Gibt es eine Möglichkeit, user_api_keys über die API abzurufen?
Nachdem wir uns über /session.json angemeldet und das aktuelle Benutzerprofil über /users/:username.json überprüft haben, können wir zwar sehen, ob der Benutzer user_api_keys hat oder nicht, aber die tatsächlichen Werte werden nicht zurückgegeben:
Der Grund, warum ich den Wert von user_api_keys abrufen möchte, ist, dass der Benutzer die Autorisierung nicht ein zweites Mal genehmigen muss, nachdem er sie bereits beim ersten Anmelden durch Klicken auf die Schaltfläche genehmigt hat.
Nein, sie werden nur einmal angezeigt und dann wird nur ein Hash gespeichert.
Der Benutzer-API-Schlüssel sollte in Ihrer App gespeichert werden, vorzugsweise auf dem Gerät des Endbenutzers. Der Grund für einen Benutzer-API-Schlüssel ist, dass er einen “Nachweis” der Autorisierung hat und für die Speicherung verantwortlich ist.
Ich glaube nicht, dass es möglich ist, den Wert eines API-Schlüssels über die API abzurufen. Discourse speichert unverschlüsselte API-Schlüssel nicht in der Datenbank. Selbst wenn Sie den verschlüsselten Wert abrufen könnten, gäbe es keine Möglichkeit, ihn in Ihrer Anwendung zu entschlüsseln.
Können Sie Ihren Anwendungsfall etwas genauer erläutern? Wenn für einen Benutzer bereits ein Benutzer-API-Schlüssel generiert wurde, ist mir nicht klar, warum er die Autorisierung ein zweites Mal genehmigen müsste.
Wenn ich meinen Beitrag noch einmal lese, stelle ich fest, dass ich nicht erklärt habe, wie die Variable $json für die Anfrage gesetzt wurde. Der einfachste Weg, um herauszufinden, wie die Daten strukturiert werden müssen, ist, eine Anfrage über die Discourse-Benutzeroberfläche zu stellen, um einen einzelnen Benutzer-API-Schlüssel mit den gewünschten Bereichen zu generieren, und dann den Wert der Anfrage-Payload zu betrachten, die mit der Anfrage an /admin/api/keys gesendet wird:
Hallo @simon, danke für deine Antwort. Lass mich unseren Fall genauer erläutern.
Wir entwickeln eine mobile App, die auf Backend-Logik von Discourse-Endpunkten angewiesen ist. Wenn sich ein Benutzer über die App anmeldet, werden die Anmeldedaten über session.json an die Discourse-API gesendet, die einen Cookie zurückgibt. Dieser Cookie wird dann verwendet, um die Webview zu /user-api-key/new umzuleiten, wodurch der Benutzer aufgefordert wird, die Autorisierung zu genehmigen. Nach der Genehmigung wird die Nutzlast in API-Schlüssel entschlüsselt.
In diesem Fall können wir die API-Schlüssel als globalen Token innerhalb der mobilen App verwenden, um auf andere Discourse-Endpunkte zuzugreifen. Wenn sich der Benutzer jedoch abmeldet, sollte der Token aus dem globalen Zustand entfernt werden, damit er nicht auf Endpunkte wie das Erstellen eines neuen Themas zugreifen kann.
Meine Frage bezieht sich auf dieses Thema: Wie können wir überprüfen, ob ein Benutzer bereits user_api_keys hat und ob diese noch aktiv sind? Wenn die Schlüssel vorhanden und aktiv sind, sollte der Benutzer sie nach der Anmeldung verwenden können. Andernfalls muss der Benutzer neue user_api_keys erstellen, was eine Genehmigung in der Webview erfordert.
Dies ist das Hauptproblem, mit dem ich konfrontiert bin.
Eine weitere Lösung, die ich in Betracht gezogen habe, basierend auf einem Beitrag von How to Retrieve User API Keys Value via API, ist die Speicherung der API-Schlüssel in der Datenbank unserer mobilen App.
Ich habe auch den Beitrag Generate User API Key Without User Approval - #2 von simon konsultiert, den ich ursprünglich für die Implementierung von API-Schlüsseln angesehen hatte. Das Problem bleibt jedoch dasselbe: Wenn wir /admin/api/keys überprüfen, können wir den Wert der bereits in der Datenbank gespeicherten API-Schlüssel nicht abrufen oder API-Schlüssel pro Benutzer erhalten. Ich glaube, für diese Implementierung müssten wir die API-Schlüssel in unserer eigenen Datenbank speichern.
Vielleicht könnten Sie ein Sitzungstoken generieren, das vom API-Schlüssel getrennt ist. Verwenden Sie dieses Token, um den Anmeldestatus des Benutzers anzuzeigen. Auf diese Weise müssten Sie den API-Schlüssel nicht löschen, wenn sich der Benutzer abmeldet.
Vielen Dank für Ihre Anregungen zu diesem Problem. Ich stimme zu, dass es besser ist, das Token an zwei Stellen zu speichern: erstens im globalen Zustand, um den Anmeldestatus des Benutzers zu überprüfen, und zweitens in der Datenbank, um die user_api_keys zu speichern.
Hallo, danke für Ihren Vorschlag. Der Grund, warum wir Discourse Connect hier nicht verwenden, ist, dass wir Discourse nicht mit anderen Websites oder anderen Orten verbinden. Die gesamte Anmeldefunktionalität wird direkt über Discourse abgewickelt, und die App wird nur mit Discourse interagieren.
Ihre App ist ein anderer Ort. Ich bin ziemlich sicher, dass Sie Ihre App als Discourse Connect-Client konfigurieren möchten, damit sich Leute mit der Anmeldung bei Discourse in Ihrer App anmelden können. Dann kann Ihre App mit Discourse interagieren, denke ich. Oder vielleicht verstehe ich nicht, wie Apps funktionieren.
