我需要澄清 ASP.NET Core 应用程序在 Linux 上的设置过程。我有 Apache 作为服务器,我想将它用作反向代理。在我的 ASP.NET Core 应用程序上,我有这样的设置:
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders =
ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
});
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});
转发 header - 这些位于“如何在 Linux 上运行 ASP.NET Core”的文档中。
在 Program.cs 我有:
var host = WebHost.CreateDefaultBuilder(args)
.UseKestrel()
.UseUrls("https://*:5001")
.UseIISIntegration()
.UseStartup<Startup>()
.Build();
我的问题:
app.UseHttpsRedirection();
添加到我的项目中吗? UseUrls("https://*:5001")
https 还是可以是 http? 最佳答案
一般来说,是的。反向代理的工作方式是它们基本上接收最终用户的请求,然后通过发出新请求将请求转发到您的应用程序。来自反向代理的新请求有自己的 header ,对于您的应用程序,就好像从来没有公开请求一样。
这意味着您的应用程序只知道内部请求,因此例如也只能生成内部 URL。为了让您的应用了解外部 URL,您可以使用反向代理提供的转发 header ,以便您的应用恢复原始请求的外观。这样,您的应用程序就会知道公共(public)请求并可以正确响应它。
不必要。 HTTPS 重定向基本上是一项功能,它会通过重定向到 HTTPS 来自动响应对 HTTP 的请求。通常,您的应用程序前面的反向代理会处理此问题,因此在将其与直接公开的 Kestrel 一起使用时,此功能最有意义。
但是,如果您想在您的应用程序中使用该功能,而不是在您的反向代理内部,您仍然可以使用该功能。如果您的反向代理在 HTTP 和 HTTPS 上为您的应用程序提供服务,并且如果它还在 Forwarded header 中正确转发方案,那么您的应用程序可以正确检测到并重定向到 HTTPS。
从安全的角度来看,您的反向代理最好不要将任何 HTTP 请求转发到您的应用程序,而是自行重定向到 HTTPS。
这也取决于您希望如何在内部设置您的应用程序。通常,由于您的反向代理是公开可见的,因此您不需要在内部使用 HTTPS,这通常也会以更少的开销获得更好的性能(并且它降低了证书的配置复杂性)。但在某些情况下,您甚至希望在内部使用 HTTPS,以使您的应用程序更安全并更好地保护其传输的数据。不过这完全取决于你。
我通常建议您不要使用 UseUrl()
调用,而只需使用 ASPNETCORE_URLS
环境变量来指定内部托管 URL 和端口。这样,您可以更灵活地应对环境变化,并且可以在部署应用程序时选择系统上的端口,而不必为了切换内部端口而重新编译应用程序。
如上所述,设置通常是您的反向代理托管在 HTTPS 上,并且反向代理和您的应用程序之间的内部通信可以通过 HTTP 进行。不过,您也可以完全选择在内部使用 HTTPS。
不,为了让应用程序允许它在反向代理后运行,您通常需要的是激活转发的 header 中间件(或 IISIntegration,如果您在 IIS 后运行)。其余的设置发生在反向代理上,您需要确保转发的 header 也正确设置。
关于c# - 带有 Apache 和反向代理的 Linux ASP.Net 核心,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/52365434/