Bonjour, j’aimerais poser une question concernant les user_api_keys. Je travaille actuellement à l’intégration de notre application pour utiliser les user_api_keys de Discourse pour l’autorisation. Ma question est : y a-t-il un moyen de récupérer les user_api_keys via l’API ?
Actuellement, après s’être connecté via /session.json et avoir vérifié le profil de l’utilisateur courant à l’aide de /users/:username.json, nous pouvons voir si l’utilisateur a des user_api_keys ou non, mais cela ne renvoie pas les valeurs réelles :
La raison pour laquelle je souhaite obtenir la valeur des user_api_keys est d’éviter d’obliger l’utilisateur à approuver l’autorisation une seconde fois après l’avoir déjà autorisée lors de la première connexion en cliquant sur le bouton.
Non, elles sont affichées une seule fois, puis seul un hachage est stocké.
La clé API utilisateur doit être stockée dans votre application, de préférence sur l’appareil de l’utilisateur final. La raison d’être d’une clé API utilisateur est qu’elle constitue une « preuve » d’autorisation et que l’utilisateur est responsable de son stockage.
Je ne pense pas qu’il soit possible de récupérer la valeur d’une clé d’API via l’API. Discourse ne sauvegarde pas les clés d’API non chiffrées dans la base de données. Même si vous pouviez récupérer la valeur chiffrée, il n’y aurait aucun moyen de la déchiffrer sur votre application.
Pouvez-vous expliquer un peu plus votre cas d’utilisation ? Si une clé d’API utilisateur a déjà été générée pour un utilisateur, je ne vois pas pourquoi il devrait approuver l’autorisation une seconde fois.
En relisant mon message, je constate que je n’ai pas expliqué comment la variable $json était définie pour la requête. La façon la plus simple de structurer les données est de faire une requête pour générer une seule clé d’API utilisateur avec les scopes que vous souhaitez utiliser via l’interface utilisateur de Discourse, puis de regarder la valeur de la charge utile de la requête envoyée à /admin/api/keys :
Salut @simon, merci pour ta réponse. Laisse-moi t’expliquer notre cas plus en détail.
Nous construisons une application mobile qui repose sur la logique backend des points d’accès Discourse. Lorsqu’un utilisateur se connecte via l’application, les données de connexion sont envoyées à l’API Discourse via session.json, qui renvoie un cookie. Ce cookie est ensuite utilisé pour rediriger la webview vers /user-api-key/new, invitant l’utilisateur à approuver l’autorisation. Après approbation, la charge utile est déchiffrée en clés API.
Dans ce cas, nous pouvons utiliser les clés API comme un jeton global dans l’application mobile pour accéder à d’autres points d’accès Discourse. Cependant, lorsque l’utilisateur se déconnecte, le jeton doit être supprimé de l’état global afin qu’il ne puisse pas accéder à des points d’accès tels que la création d’un nouveau sujet.
Ma question porte sur ce sujet : comment pouvons-nous vérifier si un utilisateur possède déjà des user_api_keys et s’ils sont toujours actifs ? Si les clés existent et sont actives, l’utilisateur devrait pouvoir les utiliser après la connexion. Sinon, l’utilisateur devra créer de nouvelles user_api_keys, ce qui nécessiterait une approbation dans la webview.
J’ai également consulté le post Générer une clé API utilisateur sans approbation de l’utilisateur - #2 par simon, que j’avais initialement consulté pour l’implémentation des clés API. Cependant, le problème reste le même : lorsque je vérifie /admin/api/keys, nous ne pouvons pas récupérer la valeur des clés API déjà enregistrées dans la base de données ni obtenir les clés API par utilisateur. Je pense que, pour cette implémentation, nous devrions stocker les clés API dans notre propre base de données.
Peut-être pourriez-vous générer un jeton de session distinct de la clé d’API. Utilisez ce jeton pour indiquer l’état de connexion de l’utilisateur. De cette façon, vous n’auriez pas besoin de supprimer la clé d’API lorsque l’utilisateur se déconnecte.
Merci pour votre contribution sur ce problème. Je suis d’accord qu’il est préférable de stocker le jeton à deux endroits : premièrement, dans l’état global pour vérifier le statut de connexion de l’utilisateur, et deuxièmement, dans la base de données pour stocker les user_api_keys.
Bonjour, merci pour votre suggestion. La raison pour laquelle nous n’utilisons pas Discourse Connect ici est que nous ne connectons pas Discourse à d’autres sites Web ou à d’autres endroits. Toutes les fonctionnalités de connexion seront gérées directement par Discourse, et l’application n’interagira qu’avec Discourse.
Votre application est un autre endroit. Je suis à peu près sûr que vous voulez configurer votre application pour qu’elle soit un client Discourse Connect afin que les gens puissent se connecter à votre application en se connectant à Discourse. Ensuite, votre application pourra interagir avec Discourse, je pense. Ou peut-être que je ne comprends pas comment fonctionnent les applications.
