Benutzer-API-Schlüssel ohne Benutzer genehmigung generieren

[BrainFried]

Ich verwende Discourse headless und kann Benutzerinformationen mit dem Admin API-Schlüssel abrufen. Es wurde jedoch empfohlen, stattdessen einen Benutzer-API-Schlüssel für jeden Benutzer zu generieren. Ich versuche also, diese Methode stattdessen zu verwenden, aber ich möchte nicht, dass der Benutzer zu einer neuen Benutzeroberfläche navigieren muss, um die API zu “genehmigen”, die ich für ihn erstelle.

Meine Lösung ist also, die Bestätigung programmatisch zu übermitteln. Von einer GET-Anfrage an ‘/user-api-key/new’ kann ich die Daten des ‘form’-Elements extrahieren, aber ich kann keine POST-Anfrage an ‘/user-api-key/’ senden, da ich einen CSRF-Fehler erhalte.

Ich habe den CSRF-Schutz für Discourse Connect deaktiviert, aber gibt es einen anderen für API-Schlüssel?
SiteSetting.discourse_connect_csrf_protection

Wenn nicht, werde ich die Benutzer-API-Schlüssel nicht verwenden, bis ich sie ohne UI-Unterbrechung erstellen kann.

Vielen Dank im Voraus!

Anscheinend gab es in früheren Versionen eine Lösung, die funktionieren könnte, aber ich sehe keine aktualisierte Version davon:

How to programmatically generate user api key

Hi According with the docs it may be possible to create an user api key from an admin user via the rest API generate api key for a user from an admin user In previous versions it worked as “admin/users/’+ user_id +’/generate_api_key”. I don’t know why in latest version it changes. Thank you for your help

[simon]

@BrainFried

Ich benutze Discourse Headless

Vielleicht bauen wir das Gleiche obwohl meines nur teilweise headless ist.

@BrainFried

gibt es noch eine für api-key?
SiteSetting.discourse_connect_csrf_protection

Ich vermute, dass es keine gibt, und dass das beabsichtigt ist.

@BrainFried

Ich möchte nicht, dass der Benutzer zu einer neuen Benutzeroberfläche navigieren muss, um die API, die ich für ihn erstelle, zu „genehmigen“.

Ich habe mich das Gleiche gefragt, aber ich denke, in meinem Fall wird es in Ordnung sein - ich versuche nicht, Discourse zu verstecken.

Eine Sache, die man bei Benutzer-API-Schlüsseln im Vergleich zu Admin-API-Schlüsseln für alle Benutzer beachten sollte, ist, dass standardmäßig unterschiedliche Ratenbegrenzungen für sie gelten: Available settings for global rate limits and throttling.

Benutzer-API-Ratenbegrenzung:
DISCOURSE_MAX_USER_API_REQS_PER_MINUTE: Standard 20
DISCOURSE_MAX_USER_API_REQS_PER_DAY: Standard 2880

Admin-API-Ratenbegrenzung:
DISCOURSE_MAX_ADMIN_API_REQS_PER_MINUTE: 60

Wenn Ihre Anwendung eine Verbindung zu einer selbst gehosteten Discourse-Site herstellt, können Sie wahrscheinlich die Admin-API-Ratenbegrenzung überschreiben. Wenn Ihre Anwendung eine Verbindung zu gehosteten Discourse-Instanzen herstellt, bieten die Benutzer-API-Ratenbegrenzungen mehr Flexibilität. Mit der Admin-API-Ratenbegrenzung müssen Sie alle Anfragen in eine ratenbegrenzte Warteschlange stellen.

Bearbeitung: Anstatt die User API Keys Specification zum Generieren der Schlüssel zu verwenden, können Sie einen Admin-API-Schlüssel zum Generieren von Benutzer-API-Schlüsseln verwenden. Das umgeht das Problem, dass Benutzer die App genehmigen müssen.

Beachten Sie, dass der unten gepostete Schlüssel für meine localhost-Domain bestimmt ist, sodass kein Risiko besteht, ihn zu posten.

unescaped key params: {key:description:sally} {key:username:sally} {key:scopes:[scope_id:topics:write]} {key:scopes:[key:write]} {key:scopes:[name:write]} {key:scopes:[params:[topic_id]]} {key:scopes:[urls:[/posts (POST)]]} {key:scopes:[selected:true]}

❯ curl -X POST \"http://localhost:4200/admin/api/keys\" \
      -H \"Api-Key: $api_key\" \
      -H \"Api-Username: system\" \
      -H \"Content-Type: application/json\" \
      -d $json
{\"key\":{\"id\":29,\"key\":\"f5c6307b51dd2882bde525dc9775fe7504b55c93fa40177b650f9e6b77a9d25b\",\"truncated_key\":\"f5c6\",\"description\":\"sally\",\"last_used_at\":null,\"created_at\":\"2024-06-02T00:44:19.944Z\",\"updated_at\":\"2024-06-02T00:44:19.944Z\",\"revoked_at\":null,\"user\":{\"id\":3,\"username\":\"sally\",\"avatar_template\":\"/user_avatar/127.0.0.1/sally/{size}/58_2.png\"},\"api_key_scopes\":[{\"resource\":\"topics\",\"action\":\"write\",\"parameters\":[\"topic_id\"],\"urls\":[\"/posts (POST)\"],\"allowed_parameters\":{},\"key\":\"write\"}]}}

In beiden Fällen haben Sie einen API-Schlüssel, der irgendwie verwaltet werden muss. Ich gehe davon aus, dass er verschlüsselt und in einer Datenbank gespeichert wird.

[BrainFried]

Verwenden Sie React für Ihr Frontend? Ich bin offen dafür, einen Weg zur Zusammenarbeit zu finden, um Redundanzen zu reduzieren und die Codezuverlässigkeit zu erhöhen. Ich denke, die Authentifizierung über SSO war der schwierigste Teil. Hoffentlich läuft es von hier an reibungslos.

[simon]

@BrainFried

Verwendest du React für dein Frontend?

Ja, es ist eine Remix/React Router-App. Also React im Frontend, Node im Backend.

@BrainFried

Ich glaube, die Authentifizierung über SSO war der schwierigste Teil.

Ich arbeite seit Jahren damit. Schick mir hier eine Nachricht, wenn du Fragen dazu hast.

Ich versuche, etwas zu entwickeln, das gut mit den Ratenbegrenzungen einer gehosteten Discourse-Seite funktioniert. Das war der knifflige Teil. Benutzerspezifische API-Schlüssel schienen eine mögliche Lösung zu sein, aber es gibt auch eine Ratenbegrenzung pro IP-Adresse, also verwende ich wieder nur einen einzigen API-Schlüssel und stelle alle API-Anfragen in eine Warteschlange.