1

我正在开发一个带有开发、暂存和蓝绿插槽的 Azure 应用程序。身份验证由 Azure AD 处理，用户被重定向到 microsoftonline 登录页面。我昨天下载了每个插槽的发布配置文件并发布了所有三个。我在多台计算机和浏览器上对它们进行了测试，所有三个插槽都正常工作。

今天早上我再次测试了它们，只有开发槽有效。Staging 和 bluegreen 都重定向到登录页面，但一旦通过身份验证，可怕的无限重定向循环就会接管。

该站点需要 SSL，但这似乎与问题无关。当插槽工作时，通过 HTTP 或 HTTPS 访问它们都正确重定向到 HTTPS。

回复 URL 也都已设置，并且似乎与问题无关。

我不确定接下来要看什么。是否存在可能影响插槽的定期运行的 Azure 进程？为什么插槽会工作几个小时然后停止工作？

循环：（向 [app]-[slot].azurewebsites.net 发送请求 => 等待 [app]-[slot].azurewebsites.net => 等待 login.microsoftonline.com => 向 [app] 发送请求-[slot].azurewebsites.net) 等等。

4

1 回答 1

3

事实证明，这个问题是由 Microsoft 的 System.Web 的 Owin 实现中的一个半著名的错误引起的：Katana Bug #197。甚至还有一个 nuget 包，其唯一目的是提供一种解决方法，直到错误被修复。截至 2017 年 4 月，nuget 包已被下载 96,000 次。

在此处输入图像描述

从 Kentor.OwinCookieSaver nuget 包的 readme.md 中：

“这个bug让欧文设置的cookie在某些情况下神秘消失了。”

解决方法非常简单。添加 nuget 包 Kentor.OwinCookieSaver，然后在 cookie 处理中间件之前添加 KentorOwinCookieSaver 中间件。

添加这个：

app.UseKentorOwinCookieSaver();

在此之前：

app.UseCookieAuthentication(new CookieAuthenticationOptions());

如果你想了解更多，这里有一些有用的链接： Owin Cookie Saver Repo，Katana Project Bug #197

于 2017-04-24T15:34:32.870 回答