У меня есть сайт, использующий Azure B2C AD для аутентификации и использующий Graph API для обновления заявок пользователей.Заявки корректно обновляются, НО, я столкнулся с тем, что похоже на проблему распространения / синхронизации.
Проще говоря: интерфейс - .Net core 2 MVC, обращающийся к .net core webapiбэкэнд, который выполняет все манипуляции с данными и т. д. Когда пользователь входит в систему нормально?Все отлично.Претензии передаются в Web API без проблем (через токен на предъявителя, автоматически обрабатываются промежуточным программным обеспечением, безупречно).
Проблема возникает, когда мы обновляем претензии пользователей - если мы обновляем претензии через API графа, а затемнемедленно сделайте запрос на вызов сразу после (скажем, например, мы переключаем профили пользователей на сайте), возвращаемые заявки по-прежнему остаются старыми значениями претензий, а не обновленными значениями претензий.Решения, которые я пробовал:
Просто обновляю объект пользователя, когда я обновляю через Graph API (очевидно, это не работает, оно не сохраняет обратно в cookie, поэтому следующий вызовна сервер вернет пользователя через cookie со старыми значениями претензий)
Задание жестко заданных задержек после обновления заявок через API-интерфейс Graph, но перед вызовом вызова.Это работает, но, очевидно, является ужасным решением, потому что мы должны жестко закодировать наши задержки для худшего сценария приведения (и все же не можем гарантировать, что мы достаточно долго ждали)
Кэширование обновленногозначения утверждений, захват события OnTokenValidated в OpenIdConnectOptions и просто обновление там объекта User, если утверждения, возвращающиеся из вызова, не соответствуют обновленным значениям утверждений.Это сохраняет в файле cookie, поэтому все внешние вызовы теперь будут видеть новые значения утверждений, но не обновляют токен носителя (в котором все утверждения зашифрованы внутри), поэтому веб-API нене вижу обновленных значений претензий
Кэширует обновленные значения претензий и передает redirectURI вызову вызова, который попадает на определенную страницу, который просто проверяет, все ли претензии пользователя всесопоставьте обновленные значения претензий сейчас.Это работает и дает нам минимальное количество времени, чтобы мы могли видеть обновленные заявки, как только они полностью обновятся в B2C.НО, это все еще может занять несколько секунд, и в то время как он ждет, чтобы увидеть все обновленные претензии, он просто сидит там, перерабатывая в B2C и снова и снова на целевую страницу, мигая в строке заголовка, ожидая.
Мое идеальное решение было бы, если бы я мог взять # 3 выше и обновлять токен-носитель одновременно, чтобы веб-API его тоже видел.Но я не верю , что это возможно.Я надеюсь, что кто-нибудь скажет мне, что это так.Наилучшим вариантом было бы, если бы был способ просто обновить объект User, не выполняя синхронную задачу снова и снова - я пытался выяснить ChallengeAsync, различные комбинации вызовов выхода / входа с обновленным объектом пользователя с обновленными значениями утверждений, ноникто из них не работал.
Надеюсь, я просто упускаю что-то действительно глупое, и кто-то может указать, где я действительно глупо.Это избавило бы меня от головной боли.