【问题标题】:Lag in getting the new value of a custom attribute after updating it更新自定义属性后获取新值的延迟
【发布时间】:2021-09-24 22:56:43
【问题描述】:

我们为我们的应用程序编写了两个自定义策略 - verify_email 和 signup_sign_in 策略。我们向用户发送一封欢迎电子邮件(我们在注册期间不使用 otp 验证电子邮件),其中包含指向 verify_email 自定义策略的链接。该链接包含由我们的证书签名的 id_token 提示,verify_email 从 id_token 获取用户主体,从 AAD 获取用户,更新 email_verified 自定义属性,然后将用户重定向到应用程序。这是一个不会向用户显示任何 UI 的无缝过程。应用程序将无法识别令牌,因为令牌来自 verify_email 策略,因此它将用户重定向到 adb2c 中的 sign_up_sign_in 策略,并且 adb2c 将看到由 verify_email 策略创建的当前用户会话,并将用户重定向回应用程序不需要用户显式登录的声明。

我所看到的是有一半的时间,sign_up_sign_in 政策不会获得最近更新的 email_verified 声明的最新值。似乎有一个延迟,当您将声明写入 azure ad 时,有时会读取它,您得到的是旧值。是否可以针对这种滞后做些什么来确保我始终获得正确的价值?提前致谢。

【问题讨论】:

    标签: azure-ad-b2c azure-ad-b2c-custom-policy aad-b2c


    【解决方案1】:

    这是由于区域复制的 DC 基础架构中的复制延迟所致。您无法做任何事情来影响这种延迟。您需要将此视为您的工作流程/设计的一部分 - 例如,使用 id 令牌提示旅程让用户登录,不要要求用户立即再次登录。在此旅程中,您将获得所有最新声明。

    【讨论】:

    • 感谢您的回复。在“重新登录”用户之前延迟 10 秒可以解决这个问题吗?
    • 不完全是,延迟各不相同。
    • 谢谢。另一个问题是密码字段的处理方式不同吗?我们的忘记密码工作流程几乎具有相同的设置,只是应用程序在通过忘记密码自定义策略重置密码后强制用户显式登录。我不相信我们遇到过新密码因为复制延迟而没有使用的情况......
    • 密码被区别对待,这是一个对跨 DC 复制具有高度优先级的字段。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-04-29
    • 1970-01-01
    • 2023-03-12
    • 1970-01-01
    相关资源
    最近更新 更多