Comments 5
После строки
'ACCESS_TOKEN_LIFETIME': timedelta(days=30)
читать перестал.
поддерживаю. А я после сохранения accesstoken в localstorage.
Автор, @VlassaDasse, по коду получается, я не могу разлогиниться без токена? Как то это неправильно.
А вдруг я, как, админ, хочу сделать revoke_all_tocken_by_user? Как это работает?
Код вьюхи залогинивания уже есть в Django, зачем писать еще раз?
Если поставить защиту @permission_classes([IsAuthenticated]) на def profile(request, user_id) Методом перебора я могу получить профили всех пользователей. Я ж авторизован. Не надо так.
Ну и последнее. Зачем в данной реализации JWT, если django предоставляет auth by session? Ответ есть на хабре, и точно не в твою пользу :(
Также Refresh желательно прятать куда-нибудь поглубже, а не просто в localStorage
А в итоге показанный пример использует просто localStorage. Злоумышленник, добравшийся до какого-нибудь XSS, просто утянет оба токена
И стандартная сессия Django получается безопаснее в том числе в этом плане, потому что через JS сессионную HttpOnly-куку прочитать не получится
Злоумышленник, добравшийся до какого-нибудь XSS
Но если прятать его в HttplOnly-куку, получается, что токен теперь уязвим и для CSRF, и для XSS. И пряча токен в localStorage остаётся лишь уязвимость XSS. Получается из двух зол, лучше выбрать localStorage. Как считаете?
Как я уже написал, HttpOnly-куку прочитать не получится, поэтому украсть refresh-токен через XSS не получится (только временно попользоваться в рамках доступности XSS). И CSRF для refresh-токена, кажется, тоже неприменим: даже если злоумышленник сможет каким-то образом отправить refresh-запрос со стороннего сайта, прочитать ответ с присланным access-токеном он не сможет уже никак — браузер не даст доступ, если вы сами не налажаете в настройках CORS
Авторизация в Django (DRF) и React по JWT-токену