直接替换ASP.NET Core中的UserHostAddress?

本文介绍了直接替换ASP.NET Core中的UserHostAddress?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我们发现Request.UserHostAddress在ASP.NET Core(1.0 RC1)中不可用，而Request.ServerVariables["REMOTE_ADDR"]在返回时基本相同.

We discovered that Request.UserHostAddress is not available in ASP.NET Core (1.0 RC1), as well as Request.ServerVariables["REMOTE_ADDR"], which returns essentially the same.

现在我们发现HttpContext.Connection.RemoteIpAddress或HttpContext.Features.Get<IHttpConnectionFeature>()?.RemoteIpAddress是替代品，但实际上是功能的1:1替代品吗?

Now we found HttpContext.Connection.RemoteIpAddress or HttpContext.Features.Get<IHttpConnectionFeature>()?.RemoteIpAddress to be the replacement, but is it really a 1:1 replacement for the functionality?

我的意思是:Request.ServerVariables["REMOTE_ADDR"]仅返回呼叫者的直接IP地址，而不返回转发的客户地址(因此必须获取"X-FORWARDED-FOR").这就是我们在方案中所需要的:直接呼叫者地址，而不是转发者地址.但是，如果ASP.NET Core中的HttpContext.Connection.RemoteIpAddress是我们的正确选择，我们就找不到任何信息(如果没有，还有什么选择?).

What I mean: Request.ServerVariables["REMOTE_ADDR"] only returns the direct IP address of a caller, not a forwarded client address (therefore you have to get "X-FORWARDED-FOR"). And that's what we need in our scenario: the direct caller address, not the forwarded one. But we couldn't find any info if HttpContext.Connection.RemoteIpAddress in ASP.NET Core is the right choice for us (and if not, what's the alternative?).

推荐答案

将中间件插入管道后，您只会得到X-Forwarded-For替换它.因此，要启用该功能，请使用app.UseOverrideHeaders().

You only get X-Forwarded-For replacing it when you have plumbed that middleware into the pipeline. So to enable that use app.UseOverrideHeaders().

没有它，在大多数配置中，RemoteIpAddress将为127.0.0.1，因为在Kestrel的前面将有IIS.

Without it RemoteIpAddress is going to be 127.0.0.1 in most configurations, because you will have IIS in front of Kestrel.