Next.js vs Django, что реально хранить в jwt/session callbac
В связке Next.js и Django проблемы с авторизацией часто начинаются не на login, а на хранении состояния после него. В jwt и session callbacks очень легко положить лишнее, а потом фронт начинает жить на случайных полях, часть логики уезжает в session, часть в API, и через время уже непонятно, где источник правды.
В callbacks стоит хранить только то, что нужно для идентификации пользователя и доступа к API. Обычно этого достаточно: id, accessToken, refreshToken. Все остальное лучше получать из защищенного backend endpoint. Тогда session не разрастается в хранилище всего подряд, а Django остается владельцем актуальных пользовательских данных.
В итоге NextAuth держит фронтовую сессию. Django держит JWT и доменные данные. А приложение не разваливается из-за того, что в session случайно начали жить имя, лимиты, тариф, профиль и еще пол-API.
Статья на Хабр Витрина проекта: AI Chat github Проект: AI Chat Stepik: AI на Django и Next II
#nextjs #NextAuth #Django #DjangoRESTFramework #JWT #OAuth #TypeScript #Fullstack #authentication #webdevelopment
· 16.04
в django держу в jwt только userId и время жизни, всё остальное тяну из бд. роли в токен не пихаю - если права поменял а токен живой, получаешь расхождение. в session callback у nextauth только access_token для django api, ничего лишнего
ответить
коммент удалён
· 16.04
Да, рабочий вариант. Если роли и права всегда проверяются в Django, а JWT остается минимальным. Разница в refresh-механике. Когда на фронте лежит только access token, нужно отдельно решать, кто и когда будет его обновлять, следить за exp заранее или ловить 401 уже по факту. В моем проекте это делает единый auth client через interceptors, access token обновляется автоматически, запрос повторяется, а UI не тащит на себе auth-логику
ответить
ответ удалён