А
это способ переделать сессии таким образом, чтобы на стороне Django был бы только сервер ресурсов, без хранения state'а
значит будет стейт где-то в другом месте, но толку?
Size: a a a
2019 July 09
AO
значит будет стейт где-то в другом месте, но толку?
state будет в JWT
AK
значит будет стейт где-то в другом месте, но толку?
толку довольно много
А
state будет в JWT
тогда JWT нельзя будет отозвать
AO
толк в том, что это решение будет легко масштабироваться, цель - убрать state со стороны сервера ресурсов (на Django)
AO
это позволит не использовать sticky sessions и подобные хаки
AK
тогда JWT нельзя будет отозвать
с чего это? отзываются на уровне секретного ключа
А
с чего это? отзываются на уровне секретного ключа
либо отзываются сразу все, либо по одиночке
А
если для каждого свой ключ
А
но для каждого свой ключ - это сессии, а зачем тогда JWT?
AO
но для каждого свой ключ - это сессии, а зачем тогда JWT?
это возможность обеспечить простое масштабирование сервера ресурсов на базе Django
А
не должно, надо смотреть на модели и запросы
AO
а JWT может генерироать/отзывать и прочее какой-нибудь auth-сервис, внешний или внутренний
А
это возможность обеспечить простое масштабирование сервера ресурсов на базе Django
нет, только масштабирование авторизации (а оно вообще надо), и только без функциональности отзыва jwt
А
а JWT может генерироать/отзывать и прочее какой-нибудь auth-сервис, внешний или внутренний
тогда и JWT не нужны
А
вот, в purchase ошибка вылетает. Пы.сы. оно связано не с юзером а с продуктами
AO
JWT нужны чтобы проверить права доступа к ресурсу и как бы всё, можно это делать на стороне какой-нибудь прокси над Django или на стороне Django
AO
а генерировать эти самые JWT может какой-нибудь Auth0
А
JWT нужны чтобы проверить права доступа к ресурсу и как бы всё, можно это делать на стороне какой-нибудь прокси над Django или на стороне Django
это можно и без JWT, JWT тут не нужны
AO
JWT позволяют внутри себя хранить некий state