Oauthlib: Type d'octroi de code d'appareil

La spécification est toujours en brouillon https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 , mais ce sera formidable si quelqu'un commence à l'implémenter dans oauthlib. Les PR sont les bienvenus

@JonathanHuot existe-t-il une bonne documentation sur où les contributeurs peuvent commencer à ajouter cette fonctionnalité ?

Vous pouvez demander sur notre chaîne Gitter.

Comme thedrow le mentionne, nous sommes très réactifs chez Gitter. Vous pouvez également consulter les autres subventions et voir comment elles sont actuellement mises en œuvre. Notez également que nous différencions le code _client_ du code _server_, mais nous avons parfois un code commun au client et au serveur.
Si vous vous penchez sur la partie client, idéalement, vous devriez également proposer un PR à requests-oauthlib qui est le principal "client" en aval d'oauthlib.

Vous pouvez également consulter notre page de contribution https://oauthlib.readthedocs.io/en/latest/contributing.html pour des informations plus génériques.

Je suis plus intéressé par le côté serveur car je dois l'implémenter pour un projet sur lequel je travaille. Atm je l'ai fait en utilisant mon code personnalisé mais je veux vraiment le faire correctement.

Va sauter sur gitter pour discuter :)

Je ne peux pas m'empêcher de penser que laisser le côté client de côté est une mauvaise idée.

Je peux construire le côté client mais le serveur de code de périphérique lui-même est encore beaucoup de travail

Je pense juste à l'architecture nécessaire pour cela dans le contexte du support JWT TRÈS nécessaire.

@duaneking avons-nous un problème ouvert pour ce changement, peut-être pouvons-nous en discuter ? Je peux interrompre ce travail jusqu'à ce que ce changement se produise.

@duaneking , le support complet de JWT peut avoir des changements d'architecture mais cela ne devrait pas empêcher @jcampbell05 de terminer son travail. Le flux de périphérique n'a rien à voir avec JWT et ne doit pas entrer en conflit avec la nouvelle architecture JWT.
_EDIT :_ Si la nouvelle architecture de JWT implique beaucoup de refactoring, je préférerai terminer ce DeviceFlow et faire le refactoring de JWT une fois DeviceFlow terminé. Uniquement parce que personne n'a commencé cette discussion de refactoring et qu'elle est loin d'être terminée que le DeviceFlow.

Côté client, si c'est mis en place lors du premier PR, ce serait super je l'avoue. En outre, cela aide à tester l'implémentation de Device Flow elle-même.

@JonathanHuot donc j'ai pensé au client J'écris essentiellement mon propre client pour le tester de toute façon, donc je suppose que cela ne fera pas de mal non plus de l'implémenter dans cette bibliothèque.

Mon plus gros refus était d'avoir des fonctionnalités à moitié terminées; Si vous ajoutez un client, cela résout ce problème. Je vous remercie.

Je n'ai pas de bande passante pour terminer cela en ce moment - alors j'espère que quelqu'un pourra le récupérer ou peut-être que je pourrai reprendre plus tard

Pas plus dans le brouillon https://tools.ietf.org/html/rfc8628