Oauthlib: Art der Gewährung des Gerätecodes

Die Spezifikation befindet sich noch im Entwurf https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 , aber es wäre großartig, wenn jemand damit beginnen würde, sie in oauthlib zu implementieren. PRs sind willkommen

@JonathanHuot Gibt es eine gute Dokumentation darüber, wo Mitwirkende anfangen können, diese Funktion hinzuzufügen?

Sie können auf unserem Gitter-Kanal nachfragen.

Wie bereits erwähnt, sind wir bei Gitter sehr reaktiv. Sie können sich auch die anderen Stipendien ansehen und sehen, wie sie derzeit umgesetzt werden. Beachten Sie auch, dass wir den _client_-Code vom _server_-Code unterscheiden, aber wir haben manchmal gemeinsamen Code für Client und Server.
Wenn Sie sich mit dem Client-Teil befassen, sollten Sie idealerweise auch einen PR für requests-oauthlib vorschlagen, der der Haupt-"Client" hinter oauthlib ist.

Sie können auch auf unserer Contributing-Seite https://oauthlib.readthedocs.io/en/latest/contributing.html nach allgemeineren Dingen suchen.

Ich interessiere mich mehr für die Serverseite, da ich dies für ein Projekt implementieren muss, an dem ich arbeite. Atm Ich habe es mit meinem benutzerdefinierten Code gemacht, aber ich möchte es unbedingt richtig machen.

Werde auf Gitter springen, um zu diskutieren :)

Ich kann nicht umhin, das Gefühl zu haben, dass es eine schlechte Idee ist, die Kundenseite außen vor zu lassen.

Ich kann die Client-Seite bauen, aber der Geräte-Code-Server selbst ist immer noch eine Menge Arbeit

Ich denke nur an die dafür benötigte Architektur im Kontext der SEHR benötigten JWT-Unterstützung.

@duaneking haben wir ein offenes Problem für diese Änderung, vielleicht können wir darüber diskutieren? Ich kann diese Arbeit pausieren, bis diese Änderung eingetreten ist.

@duaneking , die vollständige JWT-Unterstützung kann Architekturänderungen aufweisen, sollte @jcampbell05 jedoch nicht daran hindern, seine Arbeit abzuschließen. Der Gerätefluss hat nichts mit JWT zu tun und sollte nicht mit der neuen JWT-Architektur in Konflikt stehen.
_EDIT:_ Wenn die neue JWT-Architektur viel Refactoring erfordert, ziehe ich es vor, diesen DeviceFlow fertigzustellen und das JWT-Refactoring durchzuführen, sobald DeviceFlow fertig ist. Nur weil niemand diese Refactoring-Diskussion gestartet hat und sie bei weitem nicht abgeschlossen ist als der DeviceFlow.

Was die Kundenseite betrifft, wenn es während der ersten PR implementiert wird, das wäre großartig, das gebe ich zu. Außerdem hilft es, die Device Flow-Implementierung selbst zu testen.

@JonathanHuot , also habe ich über den Client nachgedacht. Ich schreibe im Grunde meinen eigenen Client, um ihn sowieso zu testen, also denke ich, dass es auch nicht schaden wird, ihn in dieser Bibliothek zu implementieren.

Mein größter Rückschlag war, dass die Features halb fertig waren; Wenn Sie einen Client hinzufügen, wird dies behoben. Danke schön.

Ich habe im Moment keine Kapazität, um dies fertigzustellen - also kann hoffentlich jemand dies aufgreifen oder vielleicht kann ich später fortfahren

Nicht mehr im Entwurf https://tools.ietf.org/html/rfc8628