Asp.Net Core UseHttpsRedirection 中间件 vs IIS URL 重写规则答案

【问题标题】：Asp.Net Core UseHttpsRedirection middleware vs IIS URL Rewrite RuleAsp.Net Core UseHttpsRedirection 中间件 vs IIS URL 重写规则
【发布时间】：2020-04-01 17:05:26
【问题描述】：

在 ASP.NET Core 中，Microsoft recommends 使用 HTTPS 重定向和 HSTS 中间件，而不是 IIS 中的重写规则，将所有 HTTP 请求重定向到 HTTPS。

从 DevOps 的角度来看，IIS 规则很容易跨应用程序实施。我们只是在部署期间将重写部分作为 Web.Config 的一部分注入，强制应用程序通过 HTTPS。但是由于中间件方法是代码本身的一部分，现在由各个应用程序团队来实现重定向。

我们有没有办法在应用程序之间强制执行 HTTPS 重定向，同时又不会偏离 Microsoft 的建议太远？

【问题讨论】：

在 IIS 上运行的 ASP.NET Core 仍支持 URL 重写模块。如果您已经将它用于其他目的，并且知道您将在 IIS 服务器上运行 ASP.NET Core，那么继续将其用于 HTTPS 重定向和 HSTS 实施应该不成问题。我将 Microsoft 的建议读为“您应该真正使用 HTTPS 重定向和 HSTS。实现这一目标的最简单方法是使用这些跨平台工作的内置方法。”对于大多数人来说，这比“如果你在 IIS 上，安装这个单独的模块，并编写更复杂的规则”更好的指导。
“在 ASP.NET Core 中，Microsoft 建议使用 HTTPS 重定向和 HSTS 中间件，而不是在 IIS 中使用重写规则将所有 HTTP 请求重定向到 HTTPS”。你从哪里得到这样的印象？显然，微软在那篇文章的注释部分所说的恰恰相反。
谢谢@JeremyCaney。这是有道理的，这正是我们现在要做的。
@LexLi，该说明讨论了反向代理配置，我没有将我们的进程内 IIS 服务器设置视为反向代理。因此问题。 Chris 和 Jeremy 的 cmets 都对我的理解有所帮助。

标签： asp.net-core iis

【解决方案1】：

具有讽刺意味的是，推荐中间件方法的原因是因为它适用于任何部署方法，而 IIS 重写规则只会影响到 IIS 的部署。例如，如果您稍后决定将这些应用程序中的一个或多个部署到集群中，那么您可能拥有的任何 IIS 重写规则都将不再适用。在应用程序级别设置它会强制执行该应用程序的状态，而不是一种特定的部署方法。另外，请记住，并非所有内容都必须是 HTTPS。例如，在部署到 k8s 集群时，您通常会关闭此功能，因为您将在网关处使用 SSL 终止。

没有真正的方法来强制执行此中间件，您也不应该考虑上述实际不应该存在的有效情况。与往常一样，独立审查始终是您最好的选择。当一个新应用投入生产时，应该评估它是否应该强制执行 SSL，并且应该在那个阶段强制执行。

另外，FWIW，它不一定非得是或。您可以同时使用中间和 IIS 重写。在这种情况下，中间件将永远不会被有效地利用，因为所有请求都将始终是 HTTPS，因为 IIS 重写，但如果由于某种原因缺少该部分，中间件仍然作为备用。

【讨论】：

感谢克里斯的精彩文章！它确实把事情放在眼里。集群配置和 SSL 终止是我不知道的，我会记住的。感谢您抽出宝贵的时间！