Ich finde den Standardwert von allowed_user_api_auth_redirects mit „discourse://auth_redirect
Ich habe das gleiche Problem. Wenn ich die API von einer JS-Anwendung aus starte, sind die zulässigen Header automatisch: User-Api-Key, User-Api-Client-Id, obwohl ich keine Benutzer-API-Schlüssel benötige. Ich möchte lediglich einen einfachen API-Schlüssel verwenden, aber nichts funktioniert. Wenn ich versuche, Api-Key in den Headern zu übergeben, erhalte ich einen CORS-Fehler, da User-Api-Key erwartet wird. Versuche ich jedoch, User-Api-Key zu verwenden, erhalte ich 403-Fehler. Ich stecke fest. Ich würde denken, dass dies die grundlegende Verwendung der APIs ist. Ich versuche nichts Außergewöhnliches. Ich versuche einfach, einen neuen Themenbeitrag zu erstellen.
2 „Gefällt mir“
Das ist das benutzerdefinierte URI-Schema, das von der DiscourseHub-App für iOS und Android verwendet wird.
6 „Gefällt mir“
Ich habe eine Frage bezüglich der „Lese-Tokens
Du kannst Schreib-Token verwenden, wenn du den Geltungsbereich im Voraus angibst.
3 „Gefällt mir“
Natürlich ist das immer möglich. Aber ich habe das Gefühl, dass dies ein Albtraum für den Support werden könnte. Unsere Software ist an mehreren hundert Standorten installiert und wird von insgesamt mehr als 10.000 Nutzern genutzt. Wenn diese sehen, dass es ein Addon gibt, das mit Discourse verbunden ist, werden viele es sicherlich gerne nutzen wollen. Da es höchstwahrscheinlich nicht sofort funktioniert, wird dies Fragen aufwerfen und Supportarbeit von unserer Seite erfordern. Zudem entsteht Arbeit für die Administratoren der verschiedenen Discourse-Installationen. Und sehr wahrscheinlich wird nicht jeder dies zulassen – was zu Frustration führen wird.
Vielleicht konzentriere ich mich daher zunächst auf die Integration der E-Mails im Mailinglisten-Modus. Oder ist es möglich, diese beiden Aspekte zu kombinieren? Gemeint ist: Lesen der Beiträge über die API, aber Versenden per SMTP?
Hallo… ich weiß nicht, wie ich einen public_key generieren soll. Soll ich einen RSA-Generator verwenden, um ein öffentliches/privates Schlüsselpaar zu erhalten?
Falls ja, habe ich einige Online-RSA-Generatoren ausprobiert, aber ich erhalte folgenden Fehler:
OpenSSL::PKey::RSAError (Neither PUB key nor PRIV key: nested asn1 error) /var/www/discourse/app/controllers/user_api_keys_controller.rb:189:in `initialize'
Außerdem möchte ich euch fragen, ob dies für meinen Anwendungsfall geeignet ist:
Ich habe eine App und möchte im Grunde Benutzer authentifizieren und den Benutzernamen abrufen. Ist der Ablauf zur Generierung eines API-Schlüssels der einfachste Weg, um die Anmeldung des Benutzers in meiner App zu validieren? Wenn möglich, möchte ich SSO vermeiden, da dies komplizierter erscheint.
Bei mir ist es ähnlich, auch wenn ich versuche, nur den User-Api-Key (nicht Api-Key) zu verwenden, um einen Themenbeitrag zu erstellen, erhalte ich eine CSRF-Ablehnung aus der actionpack-Bibliothek.
Es sei denn, der Discourse-Server hat die CSRF-Prüfung deaktiviert, scheint das Posten von einer Drittanbieter-Desktop-App schwierig zu sein. Ich werde keinen Browser emulieren.
@sam Was hältst du davon, User-API-Schlüssel mit dem Scope read in URL-Parametern bei GET-Anfragen zu erlauben?
Der Anwendungsfall ist die Unterstützung von Integrationen wie dem Abonnieren deines Improved Bookmarks with Reminders in Google Calendar mit User-API-Schlüsseln.
5 „Gefällt mir“
Wie wäre es damit, einen spezifischen neuen Scope mit einem dritten Parameter zu erstellen, der angibt, ob ein GET-Parameter erlaubt ist. Auf diese Weise kann er nicht für andere Zwecke missbraucht werden (z. B. zum Umgehen von CORS und zum Anfordern der Discourse-API von einer anderen Website).
(Quelle)
SCOPES = {
read: [:get],
write: [:get, :post, :patch, :put, :delete],
message_bus: [[:post, 'message_bus']],
push: nil,
one_time_password: nil,
notifications: [[:post, 'message_bus'], [:get, 'notifications#index'], [:put, 'notifications#mark_read']],
session_info: [
[:get, 'session#current'],
[:get, 'users#topic_tracking_state'],
[:get, 'list#unread'],
[:get, 'list#new'],
[:get, 'list#latest']
],
+ calendar: [ [:get, 'users#bookmarks_cal', true ] ],
}
(Nebenbemerkung: Warum verwenden wir hier verschachtelte Arrays…)
10 „Gefällt mir“
Es gefällt mir, dass der API-Schlüssel auf Benutzerebene explizit als „in GET erlaubt
7 „Gefällt mir“
Ich bin super interessiert an API-Schlüsseln vom Typ „get param only“. Meine Frage ist: Plant ihr, dass Nutzer diese Schlüssel über die Benutzeroberfläche generieren können?
Wahrscheinlich, eventuell hinter einer Site-Einstellung oder mit einem Plugin. Wir planen, den Funktionsumfang etwas zu vereinheitlichen, sodass Admin-API-Schlüssel auch Berechtigungsbereiche unterstützen.
4 „Gefällt mir“
Hallo… Können Sie dieses Problem lösen? Ich habe das gleiche Problem und kann es nicht beheben. Ich habe versucht, verschiedene Arten von Schlüsseln zu übergeben, aber nichts hat funktioniert. Jegliche Hilfe wäre sehr willkommen.
Gibt es dafür Bibliotheken? Falls nicht, gibt es ein Beispiel für eine Implementierung? Ich versuche, mit PHP das Discourse-Konto eines Benutzers in einem anderen Bereich der Website zu identifizieren. Das scheint ein modifizierter OAuth-Flow zu sein, aber ich bin mir bei der Umsetzung etwas unsicher.
Insbesondere bin ich mir nicht sicher, wie man die gesamte Generierung von öffentlichen und privaten Schlüsseln durchführt.
Gibt es eine Möglichkeit, einfach OAuth 2 mit Discourse als OAuth-Anbieter zu verwenden?
2 „Gefällt mir“
Hast du das mit dem User-Api-Key geschafft? Ich erhalte ebenfalls die Meldung „Sie sind nicht berechtigt, die angeforderte Ressource anzuzeigen“.
1 „Gefällt mir“
Ich habe herausgefunden, was ich falsch gemacht habe: Das zurückgegebene Payload ist nicht der UserAPI-Schlüssel selbst, sondern ein verschlüsselter JSON-String, der mit dem privaten Schlüssel des privaten/öffentlichen Schlüsselpaares entschlüsselt werden müsste.
2 „Gefällt mir“
EDIT: Ich habe es größtenteils zum Laufen gebracht und werde eine Beschreibung liefern, sobald alles vollständig funktioniert.
Wie erhält der Client das private/öffentliche Schlüsselpaar und die ID?
Können Sie Code für das Abrufen des User-API-Schlüssels mit einer JavaScript-App bereitstellen? (Eine JavaScript-App, die einem Benutzer ermöglichen soll, API-Aufrufe an ein Discourse-Forum durchzuführen).
Ich erhalte 403-Fehler. Oder eine Fehlermeldung: Entschuldigung, wir können keine User-API-Schlüssel ausstellen. Diese Funktion wurde möglicherweise vom Site-Administrator deaktiviert (obwohl auf meiner Site die Option Zulassen der Generierung von User-API-Schlüsseln aktiviert ist).
Ich denke, das Problem könnte darin bestehen, wie das private/öffentliche Schlüsselpaar generiert wird (wie wird das gemacht?) und wie die Weiterleitung behandelt wird.
Jeder Code wird geschätzt.
Ich habe es nach einigen Versuchen und Fehlern zum Laufen gebracht.
Hier sind die grundlegenden Schritte, die ich befolge, wenn ich eine separate App habe, die ich programmiert habe, und ich möchte, dass Benutzer diese App nutzen können, um API-Aufrufe an eine Discourse-Seite zu tätigen.
Dafür muss ich ein pro-Benutzer-API-Token generieren, um im Namen jedes spezifischen Benutzers Aufrufe zu tätigen (zumindest in einer Node.js/JavaScript-Umgebung).
Hinweis: Für den JavaScript-Teil habe ich den Code, den @KengoTODA hier bereitgestellt hat, als sehr hilfreich erachtet: discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub
Hier sind die Schritte, die ich befolgt habe:
Erstens: Ein Schlüsselpaar aus öffentlicher und privater Schlüssel generieren.
Dies ist etwas, das Ihre App generieren muss – einen öffentlichen und einen privaten Schlüssel. Der GitHub-Gist bietet eine Methode dafür an.
Zweitens: Eine Redirect-URL bereitstellen.
Dies ist die URL, zu der Discourse weiterleitet und das finale API-Token im Payload bereitstellt. Wenn Sie eine Desktop-App haben (also eine ohne Browser-URL), basiert die Redirect-URL auf einem benutzerdefinierten Protokoll, das Sie eingerichtet haben und das die App öffnet, wenn die Redirect-URL im Browser eingegeben wird.
Beachten Sie, dass die Redirect-URL in den Site-Einstellungen der Ziel-Discourse-Seite freigegeben (whitelisted) sein muss.
Die Discourse-Seite muss zudem wahrscheinlich die Einstellung „Benutzer-API-Schlüssel zulassen" aktiviert haben. Weitere Informationen dazu finden Sie im Originalbeitrag zu diesem Thema unter „Site Settings".
Drittens: Den API-Anfrageaufruf an die Discourse-Request-URL senden.
Ihre App sendet also einen Aufruf an eine URL, die dieses Format hat:
https://[ihre Ziel-Discourse-Seite .com]/user-api-key-new
und folgende Parameter hinzufügt:
- Ihr App-Name
- Ihre „client_id" (Ich konnte für eine Desktop-App hostname() aus
const {hostname} = require('os')verwenden, genau wie im oben genannten GitHub-Gist) - Scopes (dies sind die Berechtigungen, die der Benutzer über die API ausführen können soll, z. B. „write", „read" usw.)
- Ihren öffentlichen Schlüssel (aus Schritt 1 oben)
- Ihre Redirect-URL (aus Schritt 2 oben)
- Nonce (dies ist ein Wert, den Sie wählen können – beispielsweise scheint die Verwendung von „1" zu funktionieren)
Viertens: Der Benutzer autorisiert Ihre App auf der Discourse-Seite, die durch die Request-URL geöffnet wird.
Wenn Sie die Request-URL erfolgreich senden, öffnet sich eine Seite auf der Discourse-Seite, die dem Benutzer mitteilt, dass Ihre App Zugriff auf die Seite möchte.
Auf dieser Seite befindet sich eine Schaltfläche, mit der der Benutzer dies zulassen kann. Wenn der Benutzer auf diese Schaltfläche klickt, leitet Discourse zur bereitgestellten Redirect-URL weiter und hängt als Parameter ?payload=[DER API-SCHLÜSSEL] an. Der API-SCHLÜSSEL hier ist der Schlüssel, den Sie in Ihrer App entschlüsseln müssen.
Fünftens: Ihre App nimmt den Redirect-URL-Wert (mit Payload-Wert) auf, und Sie entschlüsseln den API-SCHLÜSSEL.
Sie sind fast am Ziel. Ihre App muss die Redirect-URL, zu der Discourse weitergeleitet hat, analysieren und den darin enthaltenen API-Schlüssel aus dem Payload extrahieren.
Sobald Sie diesen API-Schlüssel haben, müssen Sie zwei Dinge tun:
- Den tatsächlichen Schlüssel erhalten, nicht die URL-kodierte Version: Wenn Sie einen Parameter aus einer URL erhalten, ist dieser oft URL-kodiert (mit % hier und dort usw.). Sie müssen ihn bereinigen. In JavaScript habe ich festgestellt, dass
decodeURIComponentdafür funktioniert. - Sobald Sie den bereinigten API-SCHLÜSSEL von Discourse erhalten haben, müssen Sie ihn entschlüsseln. Dafür können Sie die JavaScript-Entschlüsselung mit privaten Schlüsseln verwenden. Im Wesentlichen verwenden Sie Ihren privaten Schlüssel (im ersten Schritt oben generiert), um den bereinigten API-SCHLÜSSEL zu entschlüsseln. Es gibt einige Beispiel-Code-Schnipsel in JavaScript im oben genannten GitHub-Gist: discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub
Nachdem Sie Ihren Entschlüsselungscode ausgeführt haben, haben Sie das Token selbst, das Sie nun verwenden können, um im Namen des Benutzers authentifizierte API-Aufrufe zu tätigen.
Sechstens: Verwenden Sie das Token (d. h. den finalen, bereinigten, entschlüsselten API-SCHLÜSSEL), um API-Aufrufe im Namen des Benutzers zu tätigen.
Mit diesem Token scheint es nicht erforderlich zu sein, den Benutzernamen im API-Aufruf anzugeben. Ich finde, dass folgender Header ausreicht, wenn Sie ihn in Ihren GET-, POST-, PUT- usw. Aufrufen einfügen:
headers: {
"User-Api-Key": [das Token]
}
Und damit haben Sie hoffentlich eine funktionierende pro-Benutzer-Authentifizierungsmethode, um mit Discourse zu interagieren.
7 „Gefällt mir“
Welche Sicherheitsauswirkungen hat das Hinzufügen von Dingen zu allowed_user_api_auth_redirects? Jemand bittet darum, einen String hinzuzufügen, um die NextCloud-Integration zu unterstützen.
1 „Gefällt mir“