pro.jvm

25 December 2024 00:26

https://www.baeldung.com/spring-session

pro.jvm

25 December 2024 00:20

Не знаю как ещё объяснить

pro.jvm

25 December 2024 00:17

Хранят, не выкидывают пока не протух

pro.jvm

25 December 2024 00:16

ну чтоб новый получить

pro.jvm

25 December 2024 00:15

это безумие 😁
внутри токена должно быть время жизни, клиент (сервис) получил токен 1 раз, и дальше смотрит на этот ттл, если ок (+допуск там даж есть на лаг) то юзает

зачем его выкидывать каждый раз я прям хз

pro.jvm

25 December 2024 00:11

Ну не дудос, имею ввиду можно не слать лишние запросы

pro.jvm

25 December 2024 00:10

ну что на каждый реквест нужен новый токен

pro.jvm

25 December 2024 00:09

Всмысле такое секурити)

pro.jvm

25 December 2024 00:06

так тоже странно, что за контора у которое ТАКОЕ секурити, но при этом сервис выдачи токенов можно задудосить?

pro.jvm

25 December 2024 00:04

Мы решили кэшировать этот токен, и при повторной отправке запроса из мс1 в мс2 не идти за токеном в сервис выдачи а взять из кэша

pro.jvm

25 December 2024 00:03

У нас был кейс с системным пользователем для общения микросервисов

pro.jvm

25 December 2024 00:02

Ну в плане реального юзера надо думать

pro.jvm

25 December 2024 00:01

это как? чтобы от имени юзера делать какие то реквесты пока он не видит? 😁

pro.jvm

24 December 2024 23:03

Можно токен хранить, чтобы не дудосить сервис выдачи токенов по любому чиху. Например у access токена время жизни 15 минут, можно его в кэше подержать это время и переиспользовать этот токен пока не протух

pro.jvm

24 December 2024 21:34

Но вопрос стоит ли оно того, если у вас в jwt все влезает…

pro.jvm

25 December 2024 00:24

С сессиями, поправочка

pro.jvm

25 December 2024 00:18

Такое и спринг секурити с jwt токенами делает из коробки

pro.jvm

25 December 2024 00:17

Стейтлес же, при новом реквесте идёт за новым, чтобы не идти за новым кэширование используется

pro.jvm

25 December 2024 00:16

В том то и дело, кэширует а не выкидывает

pro.jvm

25 December 2024 00:12

Ну вот у тебя микросервисы общаются между собой, для общения нужен authorization хидер, мс чтобы его заполнить идёт за токеном

pro.jvm

25 December 2024 00:10

При желании spring security oauth2 кэширует токены и это доступно из коробки)

pro.jvm

25 December 2024 00:10

В спринг секурити такое вшито при работе с oauth2)

pro.jvm

25 December 2024 00:09

разве это не по умолчанию логика работы с jwt?

pro.jvm

25 December 2024 00:05

Ну типа токен живёт n минут, зачем при каждом межсервисном взаимодействии обращаться за новым, пока не протух можно переиспользовать

pro.jvm

25 December 2024 00:03

И там при межсервисном взаимодействии каждый раз обращение за токеном в сервис выдачи токенов был

pro.jvm

25 December 2024 00:02

зачем? это в самом токене хранится

pro.jvm

25 December 2024 00:02

Можно хранить в кэше пару - id юзера и токен

pro.jvm

24 December 2024 23:08

Рпсов чуть меньше будет в сервис выдачи токенов

pro.jvm

24 December 2024 22:44

разве не был jwt придуман чтоб его можно было не хранить?😐

pro.jvm

24 December 2024 21:34

Ну у нас там был свой oauth2.0 сервер, самописный. Мы в редис клали токен при авторизации. Ключ и есть сам токен. В редисе все данные о юзере, необходимые микросервисам. Если в редисе нет токена - считаем, что юзер не авторизован и отвечаем 401. Дальше если что он на auth-сервере если что отрефрешится или заново авторизуется и токен появится.