#c# #asp.net #identityserver3
#c# #asp.net #identityserver3
Вопрос:
В нашем приложении мы периодически сталкиваемся со сценарием, когда пользователь запрашивает новый токен в то же время, когда мы автоматически обновляем токен в фоновом режиме (через JS).)
Оба запроса используют токен обновления и попадают в конечную точку токена.
Если автоматический запрос завершается первым, инициированный пользователем запрос приводит к ошибке. Это связано с тем, что оба запроса пытаются использовать один и тот же токен обновления, но поскольку он может быть использован только один раз, он используется первым запросом, а второй запрос получает 400 неверных запросов.
Мой вопрос: каков наилучший способ обработки ответа 400 для второго запроса? В идеале я хочу повторить запрос молча, и пользователь не должен быть в курсе.
Комментарии:
1. Моя первая мысль заключается в том, что после ответа 400 от сервера идентификации клиентское приложение должно выполнить обновление (или перенаправление), чтобы обновить принцип утверждений, чтобы включить новый токен обновления.
Ответ №1:
Если это происходит, конечным резервным вариантом должна быть повторная проверка подлинности — IdentityServer не делает ничего плохого, мяч на вашей стороне.
Но — вы должны быть в состоянии сделать эту ситуацию невозможной, синхронизируя автоматическое обновление токена и пользовательский запрос токена. Если токен обновления находится в вашем приложении в одном месте, вы можете регулировать доступ к нему с помощью какого-либо механизма блокировки / разблокировки.
Этот пакет npm выглядит так, как будто он это сделает: https://www.npmjs.com/package/lock
В качестве альтернативы вы могли бы синхронизировать вызовы на сервере, подклассируя соответствующий компонент IdentityServer и используя там блокировку для каждого клиента, но IdentityServer уже сложен, для этого потребуется много блокировок в одном месте, и его нелегко масштабировать до нескольких экземпляров сервера.