F
Size: a a a
2020 April 29
AS
зачем?!
хз, мне это объясняли тем, что удобное хранилище прав получается)
J
зачем?!
чтобы каждый микросерв мог аутентифицировать пользователя, разрешить некоторые действия роли и в конце концов записать в лог, чей это был запросс
RS
хз, мне это объясняли тем, что удобное хранилище прав получается)
в моём понимании экосистема микросервисов находится за Gateway сервисом, который представляет собой публичную API. Это единственный доступный из вне сервис. Именно этот сервис отвечает за аутентификацию. А во внутренних сервисах мы просто получаем user id и авторизируем
AS
в моём понимании экосистема микросервисов находится за Gateway сервисом, который представляет собой публичную API. Это единственный доступный из вне сервис. Именно этот сервис отвечает за аутентификацию. А во внутренних сервисах мы просто получаем user id и авторизируем
ну это один из подходов, мы его тоже применяем, а кто то делает диаметрально противоположную архитектуру)
J
в моём понимании экосистема микросервисов находится за Gateway сервисом, который представляет собой публичную API. Это единственный доступный из вне сервис. Именно этот сервис отвечает за аутентификацию. А во внутренних сервисах мы просто получаем user id и авторизируем
вот получаем user id и авторизуем это N запросов на каждый сервис, и сколько таких в среднем на 1 пользовательский запрос?
RS
ну это один из подходов, мы его тоже применяем, а кто то делает диаметрально противоположную архитектуру)
я против таких подходов, потому-что считают что микросервисы это деталь имплементации системы. А детали имплементации не должны вываливаться наружу
RS
совершенно лишнее действие, когда есть JWT и ты можешь, расшарив ключ между сервисами, получать все метаданные
JWT неотменяем. Мы не можем надёжно закрыть сессию, а это в некоторых ситуациях совершенно неприемлемо с точки зрения безопасности.
x
тут же как с прометеем: вы снимаете нагрузку в виде действия на каждый запрос и превращаете ее в действие раз в какой-то период времени.
UPD: а мгновенность прям самая настоящая и не нужна. Вам надо решить 99% проблема - чтоб токен не был валиден еще 15 минут, а за несколько секунд перестал принимтаься шлюзом. Т.е. Закон Парето
UPD: а мгновенность прям самая настоящая и не нужна. Вам надо решить 99% проблема - чтоб токен не был валиден еще 15 минут, а за несколько секунд перестал принимтаься шлюзом. Т.е. Закон Парето
Всё что вы говорите, будет работать (с оговорками), но это не опровергает тезис: jwt не даёт разлогина.
J
JWT неотменяем. Мы не можем надёжно закрыть сессию, а это в некоторых ситуациях совершенно неприемлемо с точки зрения безопасности.
Само собой, где это неприемлемо, так это неприемлемо) мы же не говорим о некотором общем правиле
RS
однако, я не встречал таких сервисов, где бы 1 час задержки для истечениия токена стали бы проблемой
я рассматриваю JWT лишь как оптимизацию с trade-off’ом.
т.е. сначала в бой идут сессии, и только в крайнем случае их заменяют JWT
т.е. сначала в бой идут сессии, и только в крайнем случае их заменяют JWT
J
я рассматриваю JWT лишь как оптимизацию с trade-off’ом.
т.е. сначала в бой идут сессии, и только в крайнем случае их заменяют JWT
т.е. сначала в бой идут сессии, и только в крайнем случае их заменяют JWT
я стал мудрее и в качестве id сессий сразу выпускаю JWT, складывая их также в хранилище, а когда проект вырастает, просто выпиливаешь хранилище и указываешь на ручку access/refresh, что всегда была рядом)
RS
я стал мудрее и в качестве id сессий сразу выпускаю JWT, складывая их также в хранилище, а когда проект вырастает, просто выпиливаешь хранилище и указываешь на ручку access/refresh, что всегда была рядом)
сомнительный подход