Générer une clé API utilisateur sans approbation de l'utilisateur

Dev
1

J’utilise Discourse en mode headless et je peux obtenir des informations sur les utilisateurs à l’aide de la clé API d’administrateur, mais il m’a été recommandé de générer plutôt une API utilisateur pour chaque utilisateur. J’essaie donc d’utiliser cette méthode à la place, mais je ne veux pas que l’utilisateur ait à naviguer vers une nouvelle interface utilisateur pour « approuver » l’API que je crée pour lui.

Ma solution consiste donc à soumettre la confirmation par programme. À partir d’une requête GET vers ‘/user-api-key/new’, je suis capable d’analyser les données de l’élément ‘form’, mais je ne peux pas envoyer de requête POST vers ‘/user-api-key/’ car j’obtiendrai une erreur CSRF.

J’ai désactivé la protection CSRF pour Discourse Connect, mais y en a-t-il une autre pour les clés API ?
SiteSetting.discourse_connect_csrf_protection

Sinon, je n’utiliserai pas les clés API utilisateur tant que je ne pourrai pas les créer sans l’interruption de l’interface utilisateur.

Merci d’avance !

Apparemment, une solution qui aurait pu fonctionner existait dans les versions précédentes, mais je ne vois aucune version mise à jour de ceci :

1 « J'aime »
2

Peut-être que nous construisons la même chose :slight_smile: bien que le mien ne soit que partiellement headless.

Je suppose que non, et que c’est intentionnel.

Je me posais la même question, mais je pense que dans mon cas, cela ira - je n’essaie pas de cacher Discourse.

Une chose à garder à l’esprit concernant les clés API utilisateur par rapport aux clés API de tous les utilisateurs administrateur est qu’elles ont par défaut des limites de débit différentes : Available settings for global rate limits and throttling.

limite de débit api utilisateur :
DISCOURSE_MAX_USER_API_REQS_PER_MINUTE : par défaut 20
DISCOURSE_MAX_USER_API_REQS_PER_DAY : par défaut 2880

limite de débit api admin :
DISCOURSE_MAX_ADMIN_API_REQS_PER_MINUTE : 60

Si votre application se connecte à un site Discourse auto-hébergé, vous pouvez probablement remplacer la limite de débit de l’API admin. Si votre application se connecte à des instances Discourse hébergées, les limites de débit de l’API utilisateur offrent beaucoup plus de flexibilité. Avec la limite de débit de l’API admin, vous finissez par devoir mettre toutes les requêtes dans une file d’attente à débit limité.

Modification : au lieu d’utiliser la Spécification des clés API utilisateur pour générer les clés, vous pouvez utiliser une clé API admin pour générer des clés API utilisateur. Cela résout le problème de l’approbation de l’application par les utilisateurs.

Notez que la clé publiée ci-dessous est pour mon domaine localhost, il n’y a donc aucun risque à la publier.

paramètres de clé non échappés : {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\"}]}}

Dans tous les cas, vous vous retrouvez avec une clé API qui doit être gérée d’une manière ou d’une autre. Je suppose qu’elle est chiffrée et enregistrée dans une base de données.

5 « J'aime »
3

Utilisez-vous React pour votre frontend ? Je suis ouvert à trouver un moyen de collaborer pour réduire la redondance et augmenter la fiabilité du code. Je pense que l’authentification via SSO a été la partie la plus difficile. J’espère donc que la suite sera plus facile.

4

Oui, c’est une application Remix/React Router. Donc React pour le frontend, Node pour le backend.

J’y travaille depuis des années. Envoie-moi un message ici si tu as des questions à ce sujet.

J’essaie de créer quelque chose qui fonctionne bien avec les limites de débit des sites Discourse hébergés. C’est là que ça devient délicat. Les clés API utilisateur semblaient être un moyen possible de gérer cela, mais il y a aussi une limite de débit par adresse IP, donc je reviens à l’utilisation d’une seule clé API et à la mise en file d’attente de toutes les requêtes API.

1 « J'aime »
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.