OM
Уже решил проблему)
Size: a a a
2020 October 09
OM
А как вы в своих приложениях отдаете токены??
Сетаете в куки или в authorization headers??
Сетаете в куки или в authorization headers??
DT
Всем привет. решил осваивать nest. что можете посоветовать, материалы, источники и т.п?) Если не сложно, ответьте пожалуйста)
K
А как вы в своих приложениях отдаете токены??
Сетаете в куки или в authorization headers??
Сетаете в куки или в authorization headers??
Сессии
K
Всем привет. решил осваивать nest. что можете посоветовать, материалы, источники и т.п?) Если не сложно, ответьте пожалуйста)
Официальная документация
2020 October 10
KL
Слишком хорошая статья
https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/
https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/
KL
Вопросик: должен ли я в реализации jwt strategy каждый раз обращаться к БД? Jwt это же типа serverless
А
Вопросик: должен ли я в реализации jwt strategy каждый раз обращаться к БД? Jwt это же типа serverless
Вот меня тоже постоянно мучает этот вопрос. По идее в jwt лежит вся необходимая инфа и нужно использовать ее и не дергать каждый раз бд.
Но, что если, в бд произошли какие-то изменения с юзером, а время жизни jwt ещё не истекло.
Есть же вероятность, что в jwt будут неактуальные данные. Например, юзер уже может быть забанен, а jwt об этом знать не будет
Но, что если, в бд произошли какие-то изменения с юзером, а время жизни jwt ещё не истекло.
Есть же вероятность, что в jwt будут неактуальные данные. Например, юзер уже может быть забанен, а jwt об этом знать не будет
Ф
Вот меня тоже постоянно мучает этот вопрос. По идее в jwt лежит вся необходимая инфа и нужно использовать ее и не дергать каждый раз бд.
Но, что если, в бд произошли какие-то изменения с юзером, а время жизни jwt ещё не истекло.
Есть же вероятность, что в jwt будут неактуальные данные. Например, юзер уже может быть забанен, а jwt об этом знать не будет
Но, что если, в бд произошли какие-то изменения с юзером, а время жизни jwt ещё не истекло.
Есть же вероятность, что в jwt будут неактуальные данные. Например, юзер уже может быть забанен, а jwt об этом знать не будет
можно забаненых складывать в какой-нибудь редис с expire во время жизни токена, обращение туда должно быть сильно дешевле чем к базе.
А
Федор
можно забаненых складывать в какой-нибудь редис с expire во время жизни токена, обращение туда должно быть сильно дешевле чем к базе.
Ну так забаненные это один из вариантов.
Получается нам надо хранить все сессии в редисе для каждого юзера
Получается нам надо хранить все сессии в редисе для каждого юзера
Ф
Ну так забаненные это один из вариантов.
Получается нам надо хранить все сессии в редисе для каждого юзера
Получается нам надо хранить все сессии в редисе для каждого юзера
ну да. Или просто id'шки
Ф
Федор
ну да. Или просто id'шки
правда не совсем понятно, зачем целиком сессии хранить. Все остро необходимое - в JWT. редис - только для заблокированных сессий до истечения срока жизни токена. Там, бан или логаут
А
Мб нужно делать время жизни access минимально возможным? К пример 10 мин. тогда мы сократим время, когда возможно получить неактуальные данные, но придётся рефрешить токен очень часто. Ну и в теории увеличим безопасность
Ф
Мб нужно делать время жизни access минимально возможным? К пример 10 мин. тогда мы сократим время, когда возможно получить неактуальные данные, но придётся рефрешить токен очень часто. Ну и в теории увеличим безопасность
ну да, обычно так и делают. Два токена, один для рефреша с проверками и всем таким, другой - для собственно аутентификации
Ф
А
Я вкурсе, но у нас обычно access живет пару часов
AK
Ааа то есть мои в 1минуту в проде это всё таки паранойя