ChatGPT解决这个技术问题 Extra ChatGPT

Get the IP address of the remote host

In ASP.NET there is a System.Web.HttpRequest class, which contains ServerVariables property which can provide us the IP address from REMOTE_ADDR property value.

However, I could not find a similar way to get the IP address of the remote host from ASP.NET Web API.

How can I get the IP address of the remote host that is making the request?

Easiest way I found is here: stackoverflow.com/questions/53211824/…

A
Amicable

It's possible to do that, but not very discoverable - you need to use the property bag from the incoming request, and the property you need to access depends on whether you're using the Web API under IIS (webhosted) or self-hosted. The code below shows how this can be done.

private string GetClientIp(HttpRequestMessage request)
{
    if (request.Properties.ContainsKey("MS_HttpContext"))
    {
        return ((HttpContextWrapper)request.Properties["MS_HttpContext"]).Request.UserHostAddress;
    }

    if (request.Properties.ContainsKey(RemoteEndpointMessageProperty.Name))
    {
        RemoteEndpointMessageProperty prop;
        prop = (RemoteEndpointMessageProperty)request.Properties[RemoteEndpointMessageProperty.Name];
        return prop.Address;
    }

    return null;
}

Thanks, I was looking for this too. Minor improvement = extension class: gist.github.com/2653453
The WebAPI is for the most part very clean. It's a shame that code like this is needed for something trivial as an IP.
Is the RemoteEndpointMessageProperty the class in System.ServiceModel.Channels namespace, System.ServiceModel.dll assembly? Isn't that an assembly belonging to WCF?
@Slauma, yes, they are. ASP.NET Web API is (currently) implemented in two "flavors", self-hosted and web-hosted. The web-hosted version is implemented on top of ASP.NET, while the self-hosted one on top of a WCF listener. Notice that the platform (ASP.NET Web API) itself is hosting-agnostic, so it's possible that someone will implement a different hosting in the future and the host will surface that property (remote endpoint) differently.
Unfortunately, this does not work if you self-host using Owin (as it is recommended for Web API 2). Need another if there ...
N
Nikolai Samteladze

This solution also covers Web API self-hosted using Owin. Partially from here.

You can create a private method in you ApiController that will return remote IP address no matter how you host your Web API:

 private const string HttpContext = "MS_HttpContext";
 private const string RemoteEndpointMessage =
     "System.ServiceModel.Channels.RemoteEndpointMessageProperty";
 private const string OwinContext = "MS_OwinContext";

 private string GetClientIp(HttpRequestMessage request)
 {
       // Web-hosting
       if (request.Properties.ContainsKey(HttpContext ))
       {
            HttpContextWrapper ctx = 
                (HttpContextWrapper)request.Properties[HttpContext];
            if (ctx != null)
            {
                return ctx.Request.UserHostAddress;
            }
       }

       // Self-hosting
       if (request.Properties.ContainsKey(RemoteEndpointMessage))
       {
            RemoteEndpointMessageProperty remoteEndpoint =
                (RemoteEndpointMessageProperty)request.Properties[RemoteEndpointMessage];
            if (remoteEndpoint != null)
            {
                return remoteEndpoint.Address;
            }
        }

       // Self-hosting using Owin
       if (request.Properties.ContainsKey(OwinContext))
       {
           OwinContext owinContext = (OwinContext)request.Properties[OwinContext];
           if (owinContext != null)
           {
               return owinContext.Request.RemoteIpAddress;
           }
       }

        return null;
 }

References required:

HttpContextWrapper - System.Web.dll

RemoteEndpointMessageProperty - System.ServiceModel.dll

OwinContext - Microsoft.Owin.dll (you will have it already if you use Owin package)

A little problem with this solution is that you have to load libraries for all 3 cases when you will actually be using only one of them during runtime. As suggested here, this can be overcome by using dynamic variables. You can also write GetClientIpAddress method as an extension for HttpRequestMethod.

using System.Net.Http;

public static class HttpRequestMessageExtensions
{
    private const string HttpContext = "MS_HttpContext";
    private const string RemoteEndpointMessage =
        "System.ServiceModel.Channels.RemoteEndpointMessageProperty";
    private const string OwinContext = "MS_OwinContext";

    public static string GetClientIpAddress(this HttpRequestMessage request)
    {
       // Web-hosting. Needs reference to System.Web.dll
       if (request.Properties.ContainsKey(HttpContext))
       {
           dynamic ctx = request.Properties[HttpContext];
           if (ctx != null)
           {
               return ctx.Request.UserHostAddress;
           }
       }

       // Self-hosting. Needs reference to System.ServiceModel.dll. 
       if (request.Properties.ContainsKey(RemoteEndpointMessage))
       {
            dynamic remoteEndpoint = request.Properties[RemoteEndpointMessage];
            if (remoteEndpoint != null)
            {
                return remoteEndpoint.Address;
            }
        }

       // Self-hosting using Owin. Needs reference to Microsoft.Owin.dll. 
       if (request.Properties.ContainsKey(OwinContext))
       {
           dynamic owinContext = request.Properties[OwinContext];
           if (owinContext != null)
           {
               return owinContext.Request.RemoteIpAddress;
           }
       }

        return null;
    }
}

Now you can use it like this:

public class TestController : ApiController
{
    [HttpPost]
    [ActionName("TestRemoteIp")]
    public string TestRemoteIp()
    {
        return Request.GetClientIpAddress();
    }
}

This solution should use this namespace "System.Net.Http" to work. Since this is a class name on Assembly System.Web.Http.dll, v5.2.2.0.
@WagnerBertolini, your are correct, you need using System.Net.Http; line because your are extending HttpRequestMessage. Unless your are defining your extension in System.Net.Http namespace which is very questionable. Not sure that it is essential though, because it will be automatically added by any IDE or productivity tool. What do you think?
I was in hurry trying to finish one job here and it took me more then 20 minutes to see whats going on build error. I just copied the code and created a class for it, when compiling it was not showing the methods, when I did use "go to definition" on VS it took me to my class, and I keep not understanding whats going on, until I found the other class. Extensions are a pretty new feature and is not used all the time, since, I think that it would be a good idea to save this time.
When using OWIN, you can just use the OwinHttpRequestMessageExtensions to get the OWIN context like : request.GetOwinContext().Request.RemoteIpAddress
It should actually be var ctx = request.Properties[MsHttpContext] as HttpContextWrapper; EIf you cast, you dont need to check on null because if the cast fails, you get an exception
z
zacharydl

If you really want a one-liner and don't plan to self-host Web API:

((System.Web.HttpContextWrapper)Request.Properties["MS_HttpContext"]).Request.UserHostAddress;

R
Robin van der Knaap

Above answers require a reference to System.Web to be able to cast the property to HttpContext or HttpContextWrapper. If you don't want the reference, you are able to get the ip using a dynamic:

var host = ((dynamic)request.Properties["MS_HttpContext"]).Request.UserHostAddress;

A
Asaff Belfer

When the server is behind a proxy or a load balancer the marked solution will return the internal IP address of the proxy. In our case, our production environment is using a load balancer and our development and test environments are not so I've amended the marked solution to fit both cases in the same code.

public string GetSourceIp(HttpRequestMessage httpRequestMessage)
    {
        string result = string.Empty;

        // Detect X-Forwarded-For header
        if (httpRequestMessage.Headers.TryGetValues("X-Forwarded-For", out IEnumerable<string> headerValues))
        {
            result = headerValues.FirstOrDefault();
        }
        // Web-hosting
        else if (httpRequestMessage.Properties.ContainsKey("MS_HttpContext"))
        {
            result = ((HttpContextWrapper)httpRequestMessage.Properties["MS_HttpContext"]).Request.UserHostAddress;
        }
        // Self-hosting
        else if (httpRequestMessage.Properties.ContainsKey(RemoteEndpointMessageProperty.Name))
        {
            RemoteEndpointMessageProperty prop;
            prop = (RemoteEndpointMessageProperty)httpRequestMessage.Properties[RemoteEndpointMessageProperty.Name];
            result = prop.Address;
        }

        return result;
    }

Exactly what I'm looking for. Most prod worthy apps are behind a proxy that rewrites headers, and this is the way to deal with that..
W
Warren Rumak

The solution provided by carlosfigueira works, but type-safe one-liners are better: Add a using System.Web then access HttpContext.Current.Request.UserHostAddress in your action method.


-1 this can't be trusted in web api because HttpContext.Current is not persisted correctly throughout the task pipeline; since all request handling is asynchronous. HttpContext.Current should almost always be avoided when writing Web API code.
@Andras, I would like to know more detail why using HttpContext.Current is bad, do you know any valuable resource for this?
Hi @CuongLe; in fact - whilst the threading issue can be a problem (although not always directly if the SynchronizationContext is flowed correctly between tasks); the biggest issue with this is if your service code is ever likely to be self-hosted (testing, for example) - HttpContext.Current is a purely Asp.Net construct and doesn't exist when you self-host.
Type safety isn't everything. This code will throw a hard-to-debug NullReferenceException if used from a thread (e.g. a task awaiter, very common in modern Web API code) or in a self-hosted context. At least most of the other answers will just return null.