Verwirrung über API-authentifizierten Benutzer

[BrainFried]

Ich habe eine Frage zur Sicherheit der API-Nutzung, da ich aufgrund meiner mangelnden Erfahrung ein triviales Konzept zu übersehen scheine.

Ich habe eine Headless-Implementierung von Discourse zur Integration in mein Frontend und habe SSO für die Benutzerauthentifizierung erfolgreich aktiviert.

Mein ursprüngliches Verständnis war, dass ich SSO zur Authentifizierung als “activeUser” verwende, um activeUser-spezifische Daten von der API abzurufen. Ich sehe jetzt, dass das nicht ganz richtig ist.

Ich sehe jetzt, dass die zurückgegebenen Daten vom ‘api-username’ im Header abhängen. Aber ich verwende einen Admin-API-Schlüssel, was meiner Meinung nach bedeutet, dass ich die Daten jedes Benutzers abrufen kann, indem ich den richtigen Benutzernamen für “api-username” angebe.

Meine Frage läuft also darauf hinaus: Es scheint, dass die API kein Konzept von “activeUser” einführt und ich den aktiven Benutzer anpassen muss, indem ich den Benutzernamen über die externe ID abrufe und diesen dann während der aktiven Sitzung als api-username verwende, ist das richtig?

Wenn mein Verständnis korrekt ist, ist es dann nicht einfach für einen Hacker, den api-username im Header zu ändern, um Chat-Diskussionen für jeden Benutzer abzurufen?

Jede zusätzliche Information wäre hilfreich, um mir zu helfen, das zu verstehen. Danke!

Einige verwandte Artikel, die ich gelesen habe:

User API keys specification

Discourse contains a system for generating API keys per user if a very specific protocol is followed. This feature facilitates “application” access to Discourse instances without needing to involve moderators. High level description At a high level: Client (desktop app, browser plugin, mobile app) generates a private/public key pair and return url Client redirects to a route on discourse giving discourse its public key Discourse gets approval from user to use app Discourse generat…

Get notifications via the API

If you have an existing website or application and you would like to encourage discussion on your Discourse forum it can be helpful to display Discourse notifications inside of your application. This guide will show you how to use the Discourse API to fetch notifications for a user and how to mark them as read. The recommended way of using the API is to have your application make back-end requests to Discourse and then pass that data to the front-end/presentation layer of your application. Che…

Using Discourse API to return user data when the "Require authentication to read content on this site, disallow anonymous access." setting is checked

Hi, I enabled the setting “Require authentication to read content on this site, disallow anonymous access”. I’m making a GET request to the /users/by-external/{EXTERNAL_ID}.json endpoint, and without the above setting enabled, it returns a user perfectly fine. But when I enable the above setting, the GET request returns nothing. For reference, I have SSO enabled. Let me know if there’s a workaround or if I’m thinking about this incorrectly. Thanks in advance!

Per User API Keys Not Working

I’m following the guidance for getting per user api keys: User API keys specification. I’ve gone through the steps: client generates a public/private key pair and return url, goes to a discourse route, user gives approval to discourse to use the app, and discourse generates an api key. But when discourse sends back the API key as a “payload” in the return url, that key doesn’t work. I try to decrypt it, but I can’t. I plug that key into some standard javascript decryption (like in the answer h…

[supermathie (Michael Brown)]

@BrainFried

eine Headless-Implementierung von Discourse zur Integration in mein Frontend

@BrainFried

ist es nicht für einen Hacker einfach, den api-username im Header zu ändern, um Chat-Diskussionen für jeden Benutzer abzurufen?

Ein Admin-API-Schlüssel ist der Schlüssel zum Königreich

Stecken Sie ihn nicht in eine Frontend-App. Wenn Sie es getan haben, empfehle ich Ihnen, ihn sofort zu widerrufen.

[michaeld (Michael - Communiteq)]

@BrainFried

Wenn ich das richtig verstehe, ist es für einen Hacker nicht einfach, den api-username im Header zu ändern, um Chat-Diskussionen für jeden Benutzer abzurufen?

Sie sollten diese API niemals von einem Frontend aus verwenden, da dies tatsächlich ein Risiko darstellt (eigentlich ist das Risiko viel höher, da der Hacker alles tun kann).

Sie sollten dies vom Backend aus tun.

Wenn dies keine Option ist, sollten Sie stattdessen User API-Schlüssel verwenden.

[BrainFried]

Als Headless-Implementierung werde ich dies von meinem Frontend aus ausführen. In diesem Fall scheint es, dass ich etwas Zeit damit verbringen muss, die Diskussion zu diesem Thema zu entschlüsseln:\n\nhttps://meta.discourse.org/t/user-api-keys-specification/48536\n\nÄhnlich wie bei diesen Diskussionen wäre ich daran interessiert, den API-Schlüssel des Benutzers mithilfe meines Admin-API-Zugangs automatisch zu generieren. In meinem Flow möchte ich jedoch nicht, dass der Benutzer zu einer neuen Seite weitergeleitet wird, um meine App zu „genehmigen“. Ich möchte entweder die Genehmigung mit meinem bewährten Admin-API-Schlüssel erzwingen, oder gibt es eine Einstellung, die ich deaktivieren kann, sodass für den neuen API-Schlüssel, den ich generiere, keine zusätzliche Authentifizierung erforderlich ist?