D
а у тебя сервисы каждый на свой aud смотрят?
Size: a a a
2021 January 12
A
да, смотри https://github.com/line/armeria/blob/a4724be4640fbe699776620b8bf36a93dced6135/settings.gradle#L94 к примеру
звучит годно - единственный минус как я понимаю это в каком-то месте должен хранится мап проектов на лейблы захардкожен так ?
SE
звучит годно - единственный минус как я понимаю это в каком-то месте должен хранится мап проектов на лейблы захардкожен так ?
ну там по ссылке есть, при include проектов указываешь теги. “Захардкожен” имхо не подходит, т.к. это конфигурация
x
а у тебя сервисы каждый на свой aud смотрят?
угу(
так не делают?
так не делают?
D
x
угу(
так не делают?
так не делают?
ну это странно
D
обычно же микросервисы смотрят на 1 identity provider
D
если у тебя прям независимые сервисы, и это никак не исправить - думай в сторону отдельного токена для взаимодействий, либо подумай как получить специфичный для вызываемого сервиса токен
x
если у тебя прям независимые сервисы, и это никак не исправить - думай в сторону отдельного токена для взаимодействий, либо подумай как получить специфичный для вызываемого сервиса токен
Вообще, есть вот такой RFC - https://tools.ietf.org/html/rfc8693, но он пока нигде не реализован
Предлагают из первого сервиса, используя юзер токен и сервер креды, запрашивать токен для второго сервиса и потом использовать его. Ну и вдобавок оно регулирует ещё может ли в принципе сервис А запрашивать токен для сервиса Б от имени пользователя.
Выглядит прикольно, жаль, что пощупать пока не получается
Предлагают из первого сервиса, используя юзер токен и сервер креды, запрашивать токен для второго сервиса и потом использовать его. Ну и вдобавок оно регулирует ещё может ли в принципе сервис А запрашивать токен для сервиса Б от имени пользователя.
Выглядит прикольно, жаль, что пощупать пока не получается
D
x
Вообще, есть вот такой RFC - https://tools.ietf.org/html/rfc8693, но он пока нигде не реализован
Предлагают из первого сервиса, используя юзер токен и сервер креды, запрашивать токен для второго сервиса и потом использовать его. Ну и вдобавок оно регулирует ещё может ли в принципе сервис А запрашивать токен для сервиса Б от имени пользователя.
Выглядит прикольно, жаль, что пощупать пока не получается
Предлагают из первого сервиса, используя юзер токен и сервер креды, запрашивать токен для второго сервиса и потом использовать его. Ну и вдобавок оно регулирует ещё может ли в принципе сервис А запрашивать токен для сервиса Б от имени пользователя.
Выглядит прикольно, жаль, что пощупать пока не получается
как раз похоже на серверный токен
D
только встает вопрос, а где креды хранить?
D
если у тебя сервисов 100, каждый о каждом должен знать?
D
а общее хранилище - точка отказа
D
и замедление работы
x
если у тебя сервисов 100, каждый о каждом должен знать?
не не, там все через auth server
Используя свои client id & secret
Используя свои client id & secret
D
x
не не, там все через auth server
Используя свои client id & secret
Используя свои client id & secret
а, просто отдельный конфиг еще?
x
Вроде того
Но про точку отказа - да, согласен
Но про точку отказа - да, согласен
D
x
Вроде того
Но про точку отказа - да, согласен
Но про точку отказа - да, согласен
но если их меньше, то пойдет)
