IB
мы говорим про jwt
Size: a a a
2021 August 10
IB
то что хранится у пользователя
VO
это делается на клиенте, да?
IB
А пользователь открыл dev tools в браузере, сначала записал куку которую он поулчил, а потом снова ее сам вставил
b
тут это работает, только когда $c - (сontroller, в данном случае $client), онлайн. А если он офлайн, то у тебя $c нет для соотв. клиента
IB
Ну, строго говоря если клиент не делает никаких запросов к API то все равно что у него там локально лежит =)
IC
Тогда я хз.
IB
AK
Православный - это наверное Arch? 🙂
b
void
c
JWT всё равно лучше кешировать на стороне сервера, лучше в виде метаинфы, при каждом запросе его разбирать, проверять подпись и т.д. - дорого.
Перед укладыванием в кеш можно сходить на авторизационный сервис с проверкой валидности сессии.
Соответственно инвалидация = удаление из кеша на сервисе.
Перед укладыванием в кеш можно сходить на авторизационный сервис с проверкой валидности сессии.
Соответственно инвалидация = удаление из кеша на сервисе.
IB
А нафига тогда jwt в такой схеме? =)
c
ну может там SSO
c
собственно JWT в том числе для SSO и сделан
c
Ну и я не знаю конечной цели, я отвечал на вопрос - как инвалидировать JWT ))
IB
Вы используте JWT?
Анонимный опрос
Проголосовало: 22c
Плюс к JWT как правило прилагается refresh token с небольшим временем жизни - при обновлении токена авторизационный сервис так же скажет, что юзеру хватит ходить на сервис, достаточно. Но будет лаг, зависящий, собственно, от времени жизни refresh token
b
👍👍
IC
Тут уже все зависит от того, как определяем необходимость инвалидации. Если при каждом запросе этого пользователя мы смотрим в базу и проверяем, не забанен ли он, то при каждом запросе можем его разлогинивать. И в итоге сессия-таки истечет.
VO
но ведь храня сессию на клиенте мы хотели избавиться от базы, не?