将 ASP.NET 应用程序部署到 Azure Web 应用程序时出现 HTTP 403 错误

Posted 2023-02-19

【中文标题】将 ASP.NET 应用程序部署到 Azure Web 应用程序时出现 HTTP 403 错误

【英文标题】：HTTP 403 Error when deploying ASP.NET App to Azure Web App

【发布时间】：2019-06-09 09:42:57

【问题描述】：

我正在尝试为 ASP.NET MVC Web 应用程序构建一个暂存环境，但我从一个问题到另一个问题磕磕绊绊，最后一个是这个：HTTP 500.79 Error / System.UriFormatException when deploying ASP.NET App to Azure Web App

目前我收到 HTTP 403 - 禁止访问，“您无权查看此目录或页面。”尝试访问页面时出错。

在身份验证方面，该应用程序使用 Azure Active Directory 作为身份验证提供程序，它在本地测试（使用 Test-AAD）和生产环境中运行良好。本地应用和生产应用未使用 Azure Web 应用。我在 Azure App Service 页面上注意到可以在 Azure 中指定身份验证，但我真的不想/不需要使用它，因为所有内容都在应用程序中指定。在 web.config 中配置（ClientID、ClientSecret 和 Tenant）。反正我在 Azure 上直接填 Authentication 也没有用，所以又删了。

现在发生的情况是，重定向到 login.microsoftonline.com 上的登录页面有效，并且根据 AAD 管理员的说法，登录尝试是成功的，或者至少没有显示任何特殊性。但是，当我被重定向回我的页面时，我得到了一个通用的 403，没有任何其他信息可以帮助解决问题。

我确实检查了各种日志以获取更多详细信息，我发现的唯一特殊之处是由于一些非常奇怪的原因，所有请求都是针对一个完全乱码的 URL：

请求的 URL / 指定的回复 URL：https:\\skillmanagementtest.azurewebsites.net

根据日志实际请求的URL：https:\\Skillmanagementtest:80

我完全不知道此 URL 的来源，但是，具有该大写字母的“Skillmanagementtest”似乎是我为 Azure Web 应用程序指定的名称： Screenshot resource group items

在 CI/CD 管道期间 web.config 正在正确转换，我仔细检查了那里的身份验证设置（租户、clientID、clientSecret），但我真的不知道可能导致此问题的原因。

我在其他问题上发现的一个提示是检查 IIS 日志，但是当我尝试访问据说放置这些日志的目录时，我被拒绝访问，即使我对应用服务拥有所有者权限...

更新

经过漫长而疲惫的尝试和讨论过程，我们终于让应用程序启动并运行。我们所做的一些观察可能对其他有此或类似问题的人感兴趣：

基于角色的授权不起作用，因为我们忘记在应用注册的清单文件中指定应用角色，然后将安全组链接到应用角色。在这里查看更多信息：https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps 我们有一个 API，它只在我们公司的域中可见。由于 Azure Web App 在该域之外运行，因此尝试访问该 API 会导致内部服务器错误。我们仍然需要为此找到解决方案。 我们遇到过这样一种情况，授权后对回复 URL 的请求会从 HTTPS 重定向到 HTTP。我们已经解决了这个问题，但是由于五个人连续尝试了一些东西，我们目前不知道修复的实际是什么。我们可能会创建另一个 Azure Web 应用程序，然后它可能会揭示这部分解决方案。

【参考方案1】：

经过漫长而疲惫的尝试和讨论过程，我们终于让应用程序启动并运行。我们所做的一些观察可能对其他有此或类似问题的人感兴趣：

基于角色的授权不起作用，因为我们忘记在应用注册的清单文件中指定应用角色，然后将安全组链接到应用角色。在这里查看更多信息：https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps 我们有一个 API，它只在我们公司的域中可见。由于 Azure Web App 在该域之外运行，因此尝试访问该 API 会导致内部服务器错误。我们仍然需要为此找到解决方案。 我们遇到过这样一种情况，授权后对回复 URL 的请求会从 HTTPS 重定向到 HTTP。我们已经解决了这个问题，但是由于五个人连续尝试了一些东西，我们目前不知道修复的实际是什么。我们可能会创建另一个 Azure Web 应用程序，然后它可能会揭示这部分解决方案。

【讨论】：

感谢分享您的解决方案！

【参考方案2】：

检查以确保您的 web.config 和应用设置中的内容与您在门户中应用注册的回复 URL 中的内容相匹配。回复 URL 不匹配的地方可能有一些引用。

您使用的是 openid 示例吗？ https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect

还要确保您使用在租户下和应用程序本身具有正确权限的用户登录。我和我的同事制作了一个简短的视频，其中包含可能对这个用例有帮助的正确配置。 https://www.youtube.com/watch?v=MohaxN6fsDs

【讨论】：

感谢您的回复和教程！我将您的工作与我的工作进行了比较，并对您链接的模板做了同样的事情，但没有让它工作。然而，最终取得了进展，但我无法真正确定是什么改变导致了改变。该应用程序运行的情况已被证明是相当棘手的，因为它在公司域之外运行存在额外的挑战，这可能就是它的行为与生产版本不同的原因。此时它正在运行并且身份验证有效，但我们仍然在努力解决基于角色的授权