AA
ну могу от себя
Size: a a a
2021 August 19
АЗ
rest api / очереди
PD
Хм, откуда в rest api очереди?
Это или web-socket или цепляться на какую-нибудь кафку.
Мы решили, что это слишком сильное требование, забрать diff с трех-пяти apigw дешевле.
Это или web-socket или цепляться на какую-нибудь кафку.
Мы решили, что это слишком сильное требование, забрать diff с трех-пяти apigw дешевле.
D
и свой токен с этим списком сравнивать?
PD
Каждый прилетевший запрос с access-token - сравнить, да.
PD
Это же проверяет получатель, а не отправитель )
D
ну если список большой, + сетевой вызов
D
и куча куча всего
PD
Почему сетевой вызов?
У тебя клиент->apigw->backend (обычно)
apigw хранит списки и запрашивает их с kc раз в секунду и проверяет по списку
diff за секунду небольшой, всего токенов отозванных за 30 секунд тоже не много, а проверить наличие хэша недолго )
У тебя клиент->apigw->backend (обычно)
apigw хранит списки и запрашивает их с kc раз в секунду и проверяет по списку
diff за секунду небольшой, всего токенов отозванных за 30 секунд тоже не много, а проверить наличие хэша недолго )
PD
Если очень надо, то можно и blum прикрутить )
D
блюм вероятностная структура)
D
мне кажется для проверки токена должна быть постоянная
АЗ
а кто в итоге сравнивает токен клиента и список отозванных?
PD
PD
Можно сначала блюмом, а если по нему нашлось - то уже аккуратно. Блюм удобен для быстрого выкидывания.
D
ну получается у вас agw джобой долбит auth ?
D
и обновляет внутренний кэш/структурку?
DP
а при старте apigw как список получает? батч-запросами вычитывает его из kc?
АЗ
а у вас не бывает такого что запрос с токеном уже залетел в apigw и уже летает между различными микросервисами?
AZ
в КС отозванных токенов уже нет, поэтому при старте не надо ничего читать, как я понимаю. если только apigw не персистит себе