【问题标题】:Azure jwt token not work after swapping slots交换插槽后 Azure jwt 令牌不起作用
【发布时间】:2017-08-06 09:20:34
【问题描述】:

我在 Azure 有两个用于移动应用服务的位置:生产和开发。我还有一个可以与此移动服务一起使用的客户端应用程序。生产槽中托管的应用程序版本不包含身份验证。托管在开发槽的应用程序版本具有身份验证,并且运行良好。因此,我的客户端应用程序可以获取身份验证令牌并访问受保护的 API,并使用托管在开发插槽中的服务。当我交换这个插槽时,客户端应用程序仍然可以获得身份验证令牌,但无法访问受保护的 API。在尝试使用获取的令牌调用 API 时,我收到错误 401 未经授权。

我正在使用docs 中所述的自定义身份验证

两个插槽的配置相同:身份验证:启用,请求未通过身份验证时采取的操作:允许匿名请求,身份验证提供者:禁用。据我所知,这些插槽之间唯一的区别是 URL。看起来当服务的 url 改变时,它开始生成无效的令牌。

这可能是导致这种行为的原因吗?

【问题讨论】:

    标签: azure authentication


    【解决方案1】:

    令牌创建过程中涉及的参数之一是主机名。在我的代码中,主机名值是从 MobileAppSettings 提供的。问题是 MobileAppSettings 在插槽交换后返回开发插槽的主机名值,因此生成的令牌无效。服务重启可修复此行为。

    【讨论】:

      【解决方案2】:

      对于遇到此问题的其他人,在使用 Azure 身份验证和插槽交换时需要考虑一些其他事项。首先,Azure 团队更正了主机名问题,因此所有插槽都具有相同的主机名(您可以在每个插槽的环境设置中验证这一点)。在一个插槽上生成的令牌现在在所有其他插槽上完全有效。

      但是,生成令牌时,它会存储在每个插槽硬盘驱动器上的文件夹中,并且该文件夹不会粘在特定插槽上。这意味着如果您的客户用户使用生产槽的令牌并且您交换生产槽和暂存槽,则该客户端的令牌将不再有效(因为他们在生产槽上的令牌引用现在在暂存槽上) .

      这对您的应用来说可能是也可能不是问题。如果您要求用户经常登录,那么他们甚至可能不会注意到额外的登录需要。但是,如果您拥有持久性令牌(如大多数社交网站),那么这可能会引起一些麻烦。

      【讨论】:

        猜你喜欢
        • 2012-11-20
        • 2017-07-09
        • 2015-10-20
        • 2019-07-30
        • 2021-03-30
        • 2021-12-24
        • 1970-01-01
        • 1970-01-01
        • 2021-03-09
        相关资源
        最近更新 更多