我需要阐明Linux上ASP.NET Core应用程序的设置过程。我有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
});
转发标头-位于“如何在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?答案 0 :(得分:1)
我是否完全需要这些Forwarded标头?
通常,是的。反向代理的工作方式是,它们基本上会接收最终用户的请求,然后通过发出新请求将请求转发到您的应用。来自反向代理的新请求具有其自己的标头,对于您的应用,就好像从未公开请求一样。
这意味着您的应用仅了解内部请求,因此例如也只能生成内部URL。为了向您的应用程序介绍有关外部URL的信息,您可以使用反向代理提供的转发报头,以使您的应用程序恢复原始请求的外观。这样一来,您的应用就可以知道公开请求并可以正确响应。
我需要在项目中添加
app.UseHttpsRedirection();
吗?
不一定。 HTTPS重定向基本上是一项功能,它将通过重定向到HTTPS自动响应对HTTP的请求。通常,应用程序前面的反向代理会解决此问题,因此在直接暴露Kestrel的情况下使用此功能最有意义。
但是,如果您想在应用程序中使用此功能,而不是在反向代理中使用,则仍可以使用该功能。如果您的反向代理同时在HTTP和HTTPS上为您的应用提供服务,并且还可以在Forwarded标头中正确转发该方案,则您的应用可以正确检测到该问题并重定向到HTTPS。
从安全性的角度来看,反向代理最好不(可能更简单)不将任何HTTP请求转发到您的应用,而直接重定向到HTTPS。
我是否需要在此行中指定
UseUrls("https://*:5001")
https,或者可以是http?
这还取决于您要如何在内部设置应用。 通常,因为您的反向代理是公开可见的代理,因此您无需在内部使用HTTPS,并且通常还可以以更少的开销获得更好的性能(并且降低配置复杂性证书)。但是在某些情况下,您甚至可能希望在内部使用HTTPS,以使您的应用程序更安全并更好地保护其传输的数据。但这完全取决于您。
我通常建议您不要使用UseUrl()
调用,而只需使用ASPNETCORE_URLS
环境变量来指定内部托管URL和端口。这样,您就可以更灵活地应对环境变化,并且可以在部署应用程序时选择系统上的端口,而不必重新编译应用程序即可切换内部端口。
我的Kestrel(我的应用程序)上是否通常需要使用https,或者如果我有反向代理,我可以使用http,Apache会处理ssl吗?
如上所述,该设置通常 是您的反向代理托管在HTTPS上,并且反向代理与您的应用之间的内部通信可以通过HTTP进行。您也可以完全选择在内部使用HTTPS。
我是否需要在ASP.NET Core应用中包含任何其他代码才能使其与反向代理一起使用?
否,为了使应用程序允许它在反向代理之后运行,您通常所需要做的就是激活转发的标头中间件(如果您在IIS后面运行,则激活IISIntegration)。其余的设置都在反向代理上进行,您需要确保反向转发的头也已正确设置。