V
крокфорд рекомендует так делать. как минимум, нет проблем с this
можно писать на другом языке, проблем с this точно не будет
Size: a a a
2020 December 12
꧁岡
@ShGKme @Curly_Cina рандомботы нападают
V
поднять щиты!
М
Запускаем фотонные тарпеды.
AS
Привет, объясните, пожалуйста, такой момент. Зачем при авторизации/проверки на определённую роль (например, admin), хранить её в access токене? Ведь если я обновлю пользователя (не важно как, хоть даже напрямую через бд), токен будет с уже не актуальным payload'ом, роль не изменится, и придётся ждать, пока истечёт его время и он обновится благодаря refresh токену. Сейчас делаю так, в payload только userId, а при проверке просто вытаскиваю нужного пользователя по этому id и проверяю роль, это не правильно?)
AG
Привет, объясните, пожалуйста, такой момент. Зачем при авторизации/проверки на определённую роль (например, admin), хранить её в access токене? Ведь если я обновлю пользователя (не важно как, хоть даже напрямую через бд), токен будет с уже не актуальным payload'ом, роль не изменится, и придётся ждать, пока истечёт его время и он обновится благодаря refresh токену. Сейчас делаю так, в payload только userId, а при проверке просто вытаскиваю нужного пользователя по этому id и проверяю роль, это не правильно?)
Поэтому обычно делают короткое время жизни токена, а роль в нагрузке нужна, чтобы не бегать с проверкой прав пользователя при каждом запросе.
AS
Поэтому обычно делают короткое время жизни токена, а роль в нагрузке нужна, чтобы не бегать с проверкой прав пользователя при каждом запросе.
Да, вижу минус в обращении к бд при каждом запросе, но, что если мне нужно срочно заблокировать пользователя, т. е. выдать ему роль banned, однако это произойдёт только после обновления аксес токена.
AS
Может я что-то упустил?
AG
Да, вижу минус в обращении к бд при каждом запросе, но, что если мне нужно срочно заблокировать пользователя, т. е. выдать ему роль banned, однако это произойдёт только после обновления аксес токена.
Либо блэк-лист
AS
Либо блэк-лист
блэк-лист и для аксес, и для рефреш токена? Но разве это не такое же обращение к бд?
PS
блэк-лист и для аксес, и для рефреш токена? Но разве это не такое же обращение к бд?
да, такое же. поэтому жвт и ругают когда он используется как сессии
AG
блэк-лист и для аксес, и для рефреш токена? Но разве это не такое же обращение к бд?
Ну, можно оптимизировать за счет объема таблицы, и прочих подходов, но по сути - тот же костыль.
AS
Понял, значит, если мне нужны актуальные токены, я могу обращаться каждый раз к бд и вытягивать нужного мне пользователя и роль по id (или использовать блэк-лист). А в случае, если актуальность не сильно принципиальна, то можно просто хранить роль в самом токене. И это не будет считаться грубой "ошибкой"?
AG
Понял, значит, если мне нужны актуальные токены, я могу обращаться каждый раз к бд и вытягивать нужного мне пользователя и роль по id (или использовать блэк-лист). А в случае, если актуальность не сильно принципиальна, то можно просто хранить роль в самом токене. И это не будет считаться грубой "ошибкой"?
Не будет. Главное токен держать в надежном месте на фронте в таком случае.
AS
Не будет. Главное токен держать в надежном месте на фронте в таком случае.
Спасибо, хотя токен лучше всегда хранить в надёжном месте)
AG
Спасибо, хотя токен лучше всегда хранить в надёжном месте)
Ну, если у тебя СПА, которое общается с бэком по ресту - то это сложно.
2020 December 13
AS
Ну, если у тебя СПА, которое общается с бэком по ресту - то это сложно.
Так, в случае с СПА, где лучше access токен хранить? Я вариантов знаю не так уж и много..
AG
Так, в случае с СПА, где лучше access токен хранить? Я вариантов знаю не так уж и много..
А их нет особо. Куки не пропустит браузер (cors)
AS
Ну, если у тебя СПА, которое общается с бэком по ресту - то это сложно.
Рефреш-то понятно, но зачастую с аксес, его либо в локалке, либо в памяти клиентского приложения хранят.
AS
А их нет особо. Куки не пропустит браузер (cors)
Понял