Lorsque vous appelez user-api-key/new avec un client_id déjà utilisé par un autre utilisateur, le forum génère une erreur RecordNotUnique et échoue silencieusement avec une erreur de serveur interne.
Cela pourrait vouloir échouer avec quelque chose de moins silencieux, informant l’utilisateur qu’il existe déjà une clé API avec cet identifiant client.
Cependant, cela m’amène à la deuxième question : les clés API utilisateur sont-elles censées se comporter ainsi ? L’identifiant client est-il censé être unique entre tous les utilisateurs ?
Merci d’avoir signalé cela. J’ai cependant quelques questions pour m’aider à examiner le problème.
Pouvez-vous fournir une reproduction basique pour que je puisse déboguer cela localement ? Quel est votre cas d’utilisation pour les clés d’API utilisateur ? Utilisez-vous l’application mobile Discourse Hub ou autre chose ?
La première autorisation et les autorisations répétées réussiront en tant que premier utilisateur, mais échoueront en l’utilisant à nouveau pour un autre utilisateur sans changer le client_id.
Les clés API utilisateur sont utilisées pour permettre à l’utilisateur d’utiliser son compte de forum dans le client du jeu, afin qu’il puisse poster depuis le jeu. Nous avons également beaucoup d’utilisateurs qui les utilisent pour authentifier leurs comptes de forum sur leurs propres sites Web.
Alors que l’ID client doit être unique pour les clients du jeu, de sorte que chaque client soit répertorié comme un client distinct dans l’écran des applications. Pour le cas d’utilisation d’un site Web, vous voudrez avoir un seul ID client afin que chaque connexion ne soit pas répertoriée séparément.
Y a-t-il eu une mise à jour à ce sujet ? Il n’est toujours pas clair si le client_id doit être globalement unique au lieu d’être unique par utilisateur.
Comment cela devrait-il être implémenté pour les cas d’utilisation où un site Web n’a pas son propre système d’authentification pour les utilisateurs et ne devrait pas créer plusieurs applications d’API utilisateur ?
Définir un cookie ? Ou le déterminer en hachant quelque chose qui identifie l’utilisateur (plus quelque chose de « secret » pour que des parties externes ne puissent pas le répliquer)
Si l’application qui authentifie les utilisateurs doit être utilisée sur plusieurs ordinateurs et ne dispose d’aucune donnée utilisateur avant l’authentification, c’est impossible.
Je ne comprends pas comment cela se rapporte à l’OP, car cela décrit un cas où un ID client est partagé par plusieurs utilisateurs, alors que votre cas semble décrire un utilisateur qui a plusieurs ID client.
Il est appelé un ID client et non un ID utilisateur parce qu’un utilisateur peut avoir plusieurs clients !
Dans la plupart des normes comme OAuth, l’ID client est décrit comme un « identifiant d’application » et peut être utilisé pour tous les utilisateurs (pas seulement un seul), par exemple, vos connexions sociales de forum utilisent toujours le même ID client.
Cependant, étant donné que les clés API utilisateur semblent être conçues principalement pour des clients tels que les applications Discourse, elles pourraient avoir été conçues pour être uniques, il serait donc bon de savoir si c’est le cas.
Répondre à ce qui précède permettrait de déterminer s’il manque une vérification dans user_api_keys.rb ou s’il y a un mauvais index dans la base de données. Car actuellement, ces requêtes génèrent une effrayante erreur 500 et apparaissent dans notre point de terminaison /logs.
L’erreur devrait être meilleure, oui, mais client_id doit être unique.
Lorsque vous envoyez des utilisateurs de cette manière, vous devez générer un identifiant unique dans votre appel API. L’index est correct, 1 utilisateur peut avoir N identifiants client.