Oauthlib: Тип гранта кода устройства

Созданный на 12 дек. 2018  ·  14Комментарии  ·  Источник: oauthlib/oauthlib

Опишите функцию

В последней спецификации есть тип предоставления кода устройства https://www.oauth.com/oauth2-servers/device-flow/token-request/

Это полезно для аутентификации встроенных устройств. Сейчас в этой библиотеке нет этой функции.

Contributor Friendly Feature OAuth2-Client OAuth2-Provider

Самый полезный комментарий

@JonathanHuot , поэтому я думал о клиенте. Я в основном пишу свой собственный клиент, чтобы протестировать его, так что я думаю, что реализовать его в этой библиотеке тоже не помешает.

Все 14 Комментарий

Спецификация все еще находится в черновике https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 , но будет здорово, если кто-нибудь начнет реализовывать ее в oauthlib. PR приветствуется

@JonathanHuot есть ли хорошая документация о том, где участники могут начать добавлять эту функцию?

Вы можете задать вопрос на нашем канале Gitter.

Как упоминают дроу, мы очень реактивны в Гиттере. Вы также можете ознакомиться с другими грантами и посмотреть, как они реализуются в настоящее время. Также обратите внимание, что мы отличаем код _client_ от кода _server_, но иногда у нас есть общий код для клиента и сервера.
Если вы изучаете клиентскую часть, в идеале вы также должны предложить PR для requests-oauthlib , который является основным «клиентом» после oauthlib.

Вы также можете заглянуть на нашу страницу Contributing https://oauthlib.readthedocs.io/en/latest/contributing.html для более общего материала.

Меня больше интересует серверная часть, так как мне нужно реализовать это для проекта, над которым я работаю. Atm Я сделал это, используя свой собственный код, но я очень хочу сделать это правильно.

Перескочу на гиттер, чтобы обсудить :)

Я не могу не чувствовать, что оставлять клиентскую сторону — плохая идея.

Я могу создать клиентскую часть, но сам сервер кода устройства все еще требует много работы.

Я просто думаю об архитектуре, необходимой для этого, в контексте ОЧЕНЬ необходимой поддержки JWT.

@duaneking у нас есть открытая проблема для этого изменения, может быть, мы можем это обсудить? Я могу приостановить эту работу, пока это изменение не произойдет.

@duaneking , полная поддержка JWT может иметь изменения в архитектуре, но это не должно мешать @jcampbell05 завершить свою работу. Поток устройств не имеет ничего общего с JWT и не должен конфликтовать с новой архитектурой JWT.
_EDIT:_ Если новая архитектура JWT предполагает много рефакторинга, я предпочту завершить этот DeviceFlow и выполнить рефакторинг JWT после завершения DeviceFlow. Только потому, что эту дискуссию по рефакторингу еще никто не начал и она далека от завершения, чем DeviceFlow.

Что касается клиентской стороны, если это будет реализовано во время первого PR, то это было бы здорово, признаюсь. Кроме того, это помогает протестировать саму реализацию Device Flow.

@JonathanHuot , поэтому я думал о клиенте. Я в основном пишу свой собственный клиент, чтобы протестировать его, так что я думаю, что реализовать его в этой библиотеке тоже не помешает.

Моим самым большим сопротивлением было то, что фичи были наполовину готовы; Если вы добавляете клиента, это решает эту проблему. Спасибо.

У меня нет пропускной способности, чтобы закончить это прямо сейчас, так что, надеюсь, кто-нибудь сможет это поднять, или, возможно, я смогу возобновить позже.

Нет больше черновика https://tools.ietf.org/html/rfc8628

Была ли эта страница полезной?
0 / 5 - 0 рейтинги