我已经在本地测试了一段时间的Blazor服务器应用程序（ASP.NET Core 6.0），没有任何问题。它针对Azure AD进行身份验证，一切正常。
我将其部署到Windows Server 2019上的IIS 10服务器（在安装Websockets，ASP.NET托管运行时等之后），现在我无法通过身份验证，无论是在服务器上本地还是远程。
当我点击URL时，它立即重定向到Microsoft登录页面，在那里我输入我的用户名（电子邮件），然后密码，然后2FA挑战，然后是是/否保持登录页面，然后它似乎挂了一小会儿（尽管在选项卡中它不断在“工作”和“https://login.microsoft.com...”之间切换），然后它要么出现错误请求-请求太长，要么只是“我们无法登录您”。
如果是Bad Request错误，那么cookie存储将充满. AspNetCore.Correlation.xxx和. AspNetCore.OpenIdConnectNonce.xxx cookie，这使得头部过长，并创建错误请求。如果是“我们无法让您登录”错误，那么点击三个点，然后说注销并忘记，重置下一次将导致错误请求的事情。
为了检查我没有做任何愚蠢的事情，我使用Blazor Server模板创建了一个新的空白应用程序，并将其部署在我的应用程序中。完全一样的事情发生了。我可以在VS本地运行它，但发布到IIS后，完全相同的身份验证错误。
有人有什么想法或建议吗？
2条答案
按热度按时间xjreopfe1#
好吧，如果以后有人发现这个...这是一个简单的修复-但是没有错误消息指出它，直到你看得很深。
当我设置我的应用程序和Blazor模板应用程序时，我让脚手架安装程序设置它们，并从Azure API获取一个秘密，它将其放置到我的本地秘密存储中。
当我将应用程序发布到IIS时，ClientSecret没有被复制。
快速解决方案是简单地将客户端机密放入appsettings.json文件中，此时一切都立即正常。更长的解决方案是使用基于服务器的秘密存储。
显然，循环是由于客户端秘密不存在而导致的。：（
omjgkv6w2#
对于任何遇到这个问题的人来说，部署的Azure应用程序服务也遇到了类似的问题，同样陷入了对用户进行身份验证的循环中，那么答案是相似的，但不是相同的。
你可能在appsettings.json文件中有一个有效的客户端密码，所有这些似乎都在本地完美工作。当部署时，实际情况是这个值可能会被忽略，而倾向于存储在应用程序部署槽中。
要检查这一点，请使用Kudu检查部署的设置，修改部署服务器的URL，附加一个. scm。主机名和域名之间的关系。
例如代替
https://myapp.azurewebsites.net
使用
https://myapp.scm.azurewebsites.net
在“REST API”部分下，单击“应用程序设置”链接，然后搜索客户端密码（例如“AzureAD__ClientSecret”）
如果它与appsettings.json中的不匹配，则需要在Azure中的相关应用服务下修改“配置”。