Der Zweck der beiden Discourse-API-Systeme

Unterstützung
1

Ich hoffe, ich kann klären, wann und zu welchen Zwecken die beiden Discourse-API-Authentifizierungssysteme funktionieren.

(aus hier). Dies ist mein bestes Verständnis:

Die Admin-API, manchmal auch als JSON-API bezeichnet, kann verwendet werden, wenn Sie API-Aufrufe tätigen möchten, um mit einem Discourse-Forum zu interagieren und entweder:

  1. diese Aufrufe keine Authentifizierung erfordern, oder
  2. diese Aufrufe eine Authentifizierung erfordern, Sie aber auch direkte Kontrolle über das Discourse-Forum haben, sodass Sie manuell API-Schlüssel generieren können, die Ihr Forum und/oder die separate App zur Durchführung der API-Aufrufe verwenden können.

Die User-API hingegen ist dafür gedacht, wenn Sie mit einem Discourse-Forum (oder mehreren Foren) interagieren möchten, die Interaktionen eine Authentifizierung erfordern und Sie das Forum (oder die Foren), mit denen Sie interagieren möchten, nicht kontrollieren.

Eine andere Art, es auszudrücken: Die Admin-API ist für den Fall, dass Sie das Forum kontrollieren, mit dem Sie interagieren, und die User-API für den Fall, dass Sie das Forum nicht kontrollieren.

Ist das korrekt?

Zum Beispiel besagt @davids Beschreibung hier, dass die Admin-API nicht für JavaScript-Clients gedacht ist. Ich bin jedoch der Meinung, dass es in Ordnung ist, die Admin-API mit JavaScript-Clients zu verwenden, solange der Eigentümer der App, die die JavaScript-Clients verwenden, auch das Forum kontrolliert. (Das heißt, der Eigentümer der separaten App ist derselbe wie der Eigentümer des Forums.) Richtig?

Ich würde denken, dass es so funktioniert. Wenn Sie Aufrufe an die Admin-API bezüglich einer Discourse-Seite von einer separaten App aus tätigen möchten, können Sie diese Aufrufe meiner Meinung nach serverseitig (von einem Backend aus) tätigen. Wenn Sie sie nicht von einem Backend aus tätigen – sondern von der Clientseite aus –, können Sie auf CORS-Einschränkungen stoßen. In diesem Fall können Sie die Domain der separaten App unter admin/site_settings/security/ → „cors origins

2

Wenn Sie einen API-Schlüssel in Ihrer Anwendung ausliefern, ist es für einen Hacker trivial, diesen Schlüssel aus dem Anwendungs-Binary oder dem Wire-Protokoll zu extrahieren.

Die User-API ist gegen dieses Problem immun: Der Benutzer genehmigt die Anwendung und erhält daraufhin einen dedizierten API-Schlüssel generiert.

3

Was ist der Hauptanwendungsfall für die Admin-API?

In meinem Fall verwende ich sie, um:

  1. Inhalte zu meinem Forum hinzuzufügen, indem ich API-Aufrufe tätige, die Daten senden, die ich auf meinem Forum anzeige. Eine alternative Methode wäre, über ein Plugin Ember/Rails-Code hinzuzufügen, um verschiedene Datentypen zu erstellen und anzuzeigen. Ich nutze die API (zumindest vorerst), weil es aus Programmersicht viel einfacher ist, die API zu verstehen und mit JavaScript damit zu interagieren, als die Discourse-Codebasis zu meistern und sich in Ember und Rails fluide einzuarbeiten.
  2. Eine separate App, die ich habe, mit meinem Forum interagieren zu lassen.

In beiden Fällen würde die Benutzer-API nicht funktionieren, da die abzurufenden und anzuzeigenden Daten oft nicht benutzerspezifisch sind. Ich verstehe Ihren Punkt, dass man grundsätzlich keinen API-Schlüssel im Frontend exponieren möchte. Um dies zu adressieren und dennoch die Admin-API zu nutzen, verwahre ich den Schlüssel auf einem Backend, das ich von meinem Forum aus aufrufe. Das Forum exponiert also lediglich die URL des Backend-Endpunkts (was kein Problem darstellt), nicht jedoch den dort hinterlegten API-Schlüssel.

4

Die Benutzer-API wurde genau dafür entwickelt. Siehe den Quellcode von Discourse Hub für eine Referenzimplementierung.

5

Wofür ist die Admin-API gedacht?

6

Die Admin-API dient der Server-zu-Server-Kommunikation, z. B. für Aufrufe aus dem Backend einer Website.