Django DRF, JWT Token

jwt, django, drf

Рекомендуем хостинг TIMEWEB

Стабильный хостинг, на котором располагается социальная сеть EVILEG. Для проектов на Django рекомендуем VDS хостинг.

DRF: https://github.com/ilyachch/django-rest-framework-rusdoc

про JWT - можешь подсказать, как ты его планируешь использовать?
просто я сейчас делаю сервис с SPA фронтом и встал вопрос авторизации. Смотрел на JWT и что-то както не понравилось

JWT это по сути просто токен который отвечает на вопрос пользователь который пользуется данными имеит право пользоватся ими. Данный токен имеит время жизни которое можно контролировать: обнулить(онулировати токен) продлить.
По моему мнению JWT лучше и проще чем sessions.

по сути как я понял токен это такая штуковина которая создается на момент когда ты правельно ввел юсер/пасс и в дальнейшем отвечает на вопрос кто ты. т.е кабы ты авторизовался, получил свой токен а дальше когда ты пытаешся дорватся до каких то non-public data то именно по данному токену тебе отвечают да или нет

спасибо за линк!

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

я для себя сделал вывод, что надо использовать токены (есть в доке drf)

и еще,

для DRF есть 2 похожих пакета:

djangorestframework-jwt
djangorestframework-simplejwt

если честно я еще не понял в чем разница НО понял что обсалютно во всех найденных мною мануалах, djangorestframework-simplejwt используют в паре с djoser

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

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

когда устанавливаеш djangorestframework-simplejwt то в админке джанго появляетса прилажуха (по сути 2 списка):
whitelist
blacklist

из названия понятно ... как ты думаеш програмно можно делать перемешение токена туда-сюда? думаю да

https://www.vaadata.com/blog/jwt-tokens-and-security-working-principles-and-use-cases/#:~:text=Drawbacks%20of%20JWT%20tokens&text=If%20a%20user%20needs%20to,specified%20by%20the%20standard%20implementation.

If a user account needs to be blocked or deactivated, the application will have to wait for the token to expire in order for the lockout to be fully effective.
If a user needs to change their password (for instance in case of account hijacking) and if an authentication has been performed beforehand, then a token generated with the previous password will still be valid until expiry.
No “refresh” token is specified by the standard implementation. On expiry, the user will therefore have to re-authenticate.
It is not possible to destroy a token without breaching the “stateless” aspect of JWT tokens : Even if the token is deleted from the browser, it is still valid until expiry, so no real logout is possible.

https://coderoad.ru/31919067/%D0%9A%D0%B0%D0%BA-%D1%8F-%D0%BC%D0%BE%D0%B3%D1%83-%D0%BE%D1%82%D0%BE%D0%B7%D0%B2%D0%B0%D1%82%D1%8C-%D1%82%D0%BE%D0%BA%D0%B5%D0%BD-JWT

в целом, я вас понял, спасибо

но я обратил внимание вот на что:

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

я не планирую вас отговаривать - я надеялся узнать что-то новое (что и произошло)

однако, для себя я решил таки смотреть в сторону https://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication
но мне и этот вариант не очень нравится, так как эти токены нельзя экспайрить

сейчас я метаюсь между jwt с коротким временем жизни и drf токенами
причем, из коробки ни то, ни другое решение меня особо не устраивает

если у вас получится сделать то, что вас устраивает, с jwt - буду признателен, если напишете об этом (хотя бы сюда)

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

привет

у меня появился вопрос связанный с апи

представим что у нас есть приложение с двумя "интерфейсами":
1. в браузере
2. мобильное прилажение которое по апи тянет данные

само сабой нам нужен drf для реализации апи для мобильного приложения.

а как вы думаете на сколько хороша идея что апи использовать только для мобильного приложения а для браузера писать на djano template???

если честно, нужно крайне четко понимать, какой замысел у создаваемого проекта.
Мне приходилось делать проект, про который я знал, что он будет работать на достаточно старых и слабых машинах. Поэтому я делал его обычными шаблонами и не парился (с минимум или вообще без JS). Сейчас я делаю проект, для которого фронт будет отдельным JS приложением. Поэтому тут стоит исходить из задачи

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

вообще, сделав не самое малое количество проектов (и, прочитав некоторое количество книг), я для себя выявил следующую структуру проекта:

Модели (на этом уровне я для себя решил не оставлять никакой логики, типа User.objects.get(id=100).activate()) - только структура базы + некоторые вычисляемые свойства
сервисы (собственно сама логика. Кстати, последнее время я подсел на Pydantic - позволяет писать сервисы достаточно прикольно + очень сложно сделать что-то развесистое)
валидаторы (в случае и шаблонами - формы и их метод clean, в случае drf - сериализаторы и их метод validate())
представления - то, что должно обработать действия пользователя и в зависимости от этого самого действия его провалидировать и произвести некоторое действие

шаблоны - опциональный слой, так как с апи его нет

я стремлюсь к тому, чтобы представление моего ендпоинта было примерно таким:

# класс API
class CreateUserAPIView(APIView):
    auth_class = (AnonimOnly,)
    serializer = UserCreationSerializer
    service = UserCreationService

    def post(self, request, *args, **kwargs):
        serializer = self.serializer_class(data=request.data)
        serializer.is_valid(raise_exception=True)
        data = self.service(**serializer.data).execute()
        return Response(data, status=status.HTTP_201_CREATED)

# класс обычной вьюхи
class CreateUserView(View):
    form = CreateUserView
    service = UserCreationService

    def get(request, *args, **kwargs):
        form = self.form()
        return response('/path/to/template', request, {'form': form})

    def post(request, *args, **kwargs):
        form = self.form(request.POST)
        if form.is_valid():
            data = self.service(form.cleaned_data).execute()
            return response('/path/to/another/template', request, data)
        return response('/path/to/template', request, {'form': form})

по поводу "само собой" - не согласен. Можно использовать тот же GraphQL. Да и не DRF-ом единым
можно вообще самому написать все - тогда будет максимальная свобода и гибкость=)

но, справедливаости ради, DRF-а в большинстве задач хватит, да

ну и вернувшись к главному вопросу - исходя из проблемы, которую вы хотите решить
если все раскидано по слоям - написать АПИ поверх готовых сервисов и моделей - не сложно (ну или сделать генерацию из шаблонов на основе все той же структуры)

если хотите меньше головной боли - делайте все через АПИ (последнее время ловлю себя на мысли, что для того, чтобы реализовать некоторые мои затеи - придется воротить жуть в шаблонах)

если хотите поковыряться в фронтенде - посмотрите на nuxt - мне, как закоренелому бэкендеру, достаточно просто было разобраться (не надо конфигурить вебпак и прочее)

кстати, я поигрался с JWT в связке с SSR SPA приложением на JS.
реализация: refresh token в httponly куку, обычный токен - на 15 минут. фронт - nuxt
мне таки не понравилось. Аргументы в студию:

логин - тут все просто. логин+пароль - в ответ токен. токен храним в рантайме
пользователь открывает новую вкладку - делаем запрос на рефреш токена, получаем токен2, с ним делаем запросы, формируем страницу, отдаем. медленно (рефреш запрос блокирует остальные запросы), но пусть будет
токен протух - бывает. но в какой момент мы это узнаем - делать рефреш запрос кажые 5 минут? я попробовал так - получилось сделать запрос? нет? тогда рефреш и снова пробуем. но тут возникает 2 лишних запроса (а сетевое взаимодействие - долгое). получается каждые +-15 минут приложение будет подвисать. что-то как-то не очень
логаут - все оч просто. затерли токен в рантайме и нормально. но как его убрать на других вкладках? использовать localStorage? не безопасно. допустим мы используем шароковещательное сообщение, которое ловим на остальных вкладках. ок
а как убрать куку с рефреш токеном? кука - httponly (безопасность, все дела). к ней доступа из js нет. получается либо делать запрос на сервер, чтобы либо убрать ее, либо блэклистить (запрос по сети + запрос в базу + увеличение длительности рефреш запросов - надо проверять, что рефреш токен из куки не в черном списке)
и получается, если не делать дозапросов - если пользователь откроет новую вкладку, мы получим куку, обновим токен и все снова работает, хотя пользователь делал логаут. безопасность уровня "решето"

в целом, я подозреваю, что я что-то сделал не так + я не очень умею в JS, поэтому делал как умею. Но, я делал сессионную авторизацию (с небольшими танцами вопруг кроссайт запросов) и все работает крайне хорошо (+ широковещательное сообщение logout), чтобы остальные вкладки тоже вышли.

если у вас более удачный опыт - я буду крайне признателен, если поделитесь

приветствую

скажите а вы в setting.py прописали значение для пораметра: 'JWT_EXPIRATION_DELTA' ?

я писал сам все
у меня аналог этой дельты был 15 минут