pro.jvm

25 Dec 2024 00:17

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

pro.jvm

25 Dec 2024 00:16

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

pro.jvm

25 Dec 2024 00:12

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

pro.jvm

25 Dec 2024 00:10

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

pro.jvm

25 Dec 2024 00:10

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

pro.jvm

25 Dec 2024 00:09

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

pro.jvm

25 Dec 2024 00:05

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

pro.jvm

25 Dec 2024 00:03

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

pro.jvm

25 Dec 2024 00:02

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

pro.jvm

25 Dec 2024 00:02

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

pro.jvm

24 Dec 2024 23:08

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

pro.jvm

24 Dec 2024 22:44

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

pro.jvm

24 Dec 2024 21:34

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

pro.jvm

24 Dec 2024 21:26

Ну в redis например можно искать токен, если его кто-то туда заранее положил... Но по сути те же яйца, только сбоку, не могу сказать что это проще. Мы так делали, но только потому что у нас токен разросся и в целом принято было решение не все в JWT пихать.

pro.jvm

24 Dec 2024 18:21

Тут же ясно написано - эту, встроенную.

pro.jvm

25 Dec 2024 00:16

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

pro.jvm

25 Dec 2024 00:15

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

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

pro.jvm

25 Dec 2024 00:11

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

pro.jvm

25 Dec 2024 00:10

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

pro.jvm

25 Dec 2024 00:09

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

pro.jvm

25 Dec 2024 00:06

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

pro.jvm

25 Dec 2024 00:04

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

pro.jvm

25 Dec 2024 00:03

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

pro.jvm

25 Dec 2024 00:02

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

pro.jvm

25 Dec 2024 00:01

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

pro.jvm

24 Dec 2024 23:03

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

pro.jvm

24 Dec 2024 21:34

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

pro.jvm

24 Dec 2024 21:29

а что на счёт обновления токена? и по какому ключу искать этот jwt?

pro.jvm

24 Dec 2024 21:16

Всем привет. Подскажите как защитить сокеты? Я передаю jwt по заголовку (использую stomp) и там уже достаю его и проверяю самостоятельно. Может кто знает попроще что-нибудь, а то хотелось бы покрасивее как-то. В качестве единой системы входа использую keycloak

pro.jvm

24 Dec 2024 18:20

>Знакомство где-то в одном из московских ресторанов
>А ты чем занимаешься?
>Я генерал DDL