"X-Forwarded-For" should be "HTTP_X_FORWARDED_FOR"

[sboshuis]

if we look in DNN UserRequestIPAddressController.cs it will use "X-Forwarded-For" or "REMOTE_ADDR"

"X-Forwarded-For" should be "HTTP_X_FORWARDED_FOR"

Not sure if there are more places in DNN code where this is used.

We noticed this first when using DNN on azure with application firewall. There remote_addr is not used and original ip address is placed in X-Forwarded-For header.

So in e.g. admin logs all IP: will be empty.

We have tested in 9.11.0

for testing we used a simple test module and logged ip's via a function like: public string GetUserIP() { var ip = (HttpContext.Current.Request.ServerVariables["HTTP_X_FORWARDED_FOR"] != null && HttpContext.Current.Request.ServerVariables["HTTP_X_FORWARDED_FOR"] != "") ? HttpContext.Current.Request.ServerVariables["HTTP_X_FORWARDED_FOR"] : HttpContext.Current.Request.ServerVariables["REMOTE_ADDR"]; if (ip.Contains(",")) ip = ip.Split(',').First().Trim(); return ip; } And that works just fine. Just think sometimes it will contain also port using : and not , so the function is not to be used like this but pure for testing.

Having the same test but then HttpContext.Current.Request.ServerVariables["X-Forwarded-For"] like it is now in DNN is not getting anything so IP is null or empty

Sander

[bdukes]

X-Forwarded-For is used to query the Headers, whereas REMOTE_ADDR is used to query ServerVariables, so they're in different formats. This is definitely working for folks in a variety of scenarios. Can you give more details about what you're seeing?

https://github.com/dnnsoftware/Dnn.Platform/blob/ef79fdfa2c983f7b0fa5c5f98530866953301e26/DNN%20Platform/Library/Services/UserRequest/UserRequestIPAddressController.cs#L27-L32

https://github.com/dnnsoftware/Dnn.Platform/blob/ef79fdfa2c983f7b0fa5c5f98530866953301e26/DNN%20Platform/Library/Services/UserRequest/UserRequestIPAddressController.cs#L44-L51

[sboshuis]

Website hosted on Azure behind firewall. IP in logs will stay empty or will show the firewall ip.

From documentation you will find:

Application gateway inserts six additional headers to all requests before it forwards the requests to the backend. These headers are x-forwarded-for, x-forwarded-port, x-forwarded-proto, x-original-host, x-original-url, and x-appgw-trace-id. The format for x-forwarded-for header is a comma-separated list of IP:port. The valid values for x-forwarded-proto are HTTP or HTTPS. X-forwarded-port specifies the port where the request reached the application gateway.

X-original-host header contains the original host header with which the request arrived. This header is useful in Azure website integration, where the incoming host header is modified before traffic is routed to the backend. If session affinity is enabled as an option, then it adds a gateway-managed affinity cookie.

So basically x-original-host header will contain the client original IP.

For now we just changed the firewall to use X-Forwarded-For to have the original ip, but not everyone will be able to, so maybe dnn should have some config for this?

What we see is that all DNN framework IP loggin contains nothing. You are right I read wrong. you are using header to get it but result is the same for us. no ip.

So we use HttpContext.Current.Request.ServerVariables["HTTP_X_FORWARDED_FOR"] to get it and that does work for us.

I will do extra testing on the Azure site with the header code like in DNN to give you more info.

[sboshuis]

So we did the extra tests:

You are right, you can use the header for the x-forwarded-port. however we found that azure adds a port number behind the ip and the header you read is on our case 92.12.12.123:35884

So I assume the private bool ValidateIP(string ipString, IPAddressFamily ipFamily) will return as false and resulting in empty string for ip.

So on our site we will try to change Azure firewall to exclude the port.

Maybe for DNN simply split on : and take [0] just like the split on the comma?

Remains my wish for adding the used header to web.config if possible? so if nothing configured just leave as is but option to add a custom header to use?

for azure it is: "X-original-host header contains the original host header with which the request arrived. This header is useful in Azure website integration, where the incoming host header is modified before traffic is routed to the backend. "

But who knows what header is used by other WAF solutions now and in future..

Thanx Sander

[bdukes]

Ah, yes, the issue with the port was actually discussed in #5371 and fixed in #5372 for DNN 9.11.1.

The host header is the domain name of the site, not an IP address (unless you're seeing different in your testing).

You can customize the header by setting the UserRequestIPHeader host setting. It doesn't look like there's any UI to manage this, but you can set it directly in the database (e.g. INSERT INTO HostSettings (SettingName, SettingValue) VALUES ('UserRequestIPHeader', 'X-original-host header')). But, as I mentioned, I don't think that will give you the value that you want.

[valadas]

@sboshuis given #5372 and the previous comment, is this issue still valid, if so any clue on how to handle that from our codebase ?

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically. If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!