Pull to refresh

Comments 13

UFO just landed and posted this here

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

Возможно, я не очень внимательно прочитал статью, но не очень понял один момент. Вы выдаёте пользователю jwt-токен, имеющий время жизни. А что происходит в момент, когда оно истекает? Пользователя разлогинит прямо во время пользования вашей админкой/сайтом? Если да, то это не нормально. Кроме того, jwt можно валидировать без обращения к базе данных — в этом и заключается основное преимущество такого вида токенов (чтобы не лазать лишний раз в базу данных). У вас он валидируется, но после этого пользователь зачем-то ищется в базе. Какой в этом смысл, если id пользователя подделать невозможно, потому что jwt тогда станет невалидным. Так можно и обычный токен использовать вместо jwt.

Тут, по идее, нужен не только access-токен, но и второй — refresh, чтобы была реализована ротация токенов.
Это как раз следующие шаги) обрати внимание, я написал, что эта статья про основу, фундамент так сказать jwt авторизации, с которым дальше можно танцевать как душе угодно. Да, обязательно нужен refresh/, на который фронт будет ходить периодически.

Насчет генерации токена — ситуация похожа: для статьи, туториала, имхо, достаточно и этого. Быть может, когда-то созрею до продолжения, до усиления безопасности, ускорения и т.д.
Почему бы для маршрутизации не использовать DefaultRouter из самой же DRF?
Лично мне больше по душе urlpatterns, наверное дело вкуса, а может просто привык. Кроме синтаксических различий и, как следствие, удобства, есть ли какая-то большая разница между ними?
Если делать через router, а его уже подключить в urlpatterns как path('api/', include(router.urls)), то по адресу localhost:8000/api/ будет удобная «менюшка» со всеми эндпоинтами.

Простите, но я так и не понял зачем писать токен в базу


Посмотрите на вашу последнюю (в статье) функцию
она просто берет токен из http запроса, декодирует из него user_id и проверяет есть ли такой user_id (а не токен) в базе и если такой user есть и активен, то запрос авторизован


И в самом начале посмотрите как токен генерится
там простой объект (dict) с двумя полями: id и exp
этот объект шифруется с помощью серверного SECRET_KEY и отдается клиенту для дальнейшего использования.


А клиент просто в каждый http запрос вставляет заголовок с токеном (вместо сессионных куков)
curl http://localhost:5000/api/whatever -H 'Authorization: Bearer $JWT'

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

Спасибо, большое. Много полезного почерпнул. Было бы хорошо если бы выложили код на github и тут прицепили ссылку.

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

Выполняю все по инструкции, но токен не создается. Т.е. при проверке через shell вижу.Уже перепроверял, не вижу в чем проблема.
~\Desktop\Django\new_proj\django_auth\users\models.py in _generate_jwt_token(self)
     92         token = jwt.encode({
     93             'id': self.pk,
---> 94             'exp': int(dt.strftime('%s'))
     95         }, settings.SECRET_KEY, algorithm='HS256')
     96

ValueError: Invalid format string
Sign up to leave a comment.

Articles