search

dotnet / MQTTnet

MQTTnet is a high performance .NET library for MQTT based communication. It provides a MQTT client and a MQTT server (broker). The implementation is based on the documentation from http://mqtt.org/.
MIT License
4.41k stars 1.06k forks source link

X-Forward-For header is not rewriting endpoint address when ASP.NET core 3.1 is behind a reverse proxy #1000

Open Jossec101 opened 3 years ago

Jossec101 commented 3 years ago

Describe the bug

If you are using .net core 3.1 and ASP NET Core, the endpoint is never updated to match the actual HttpContext RemoteIpAddress due to the implementation introduced in: c10145f743694474489fc254a70ef8a0b73eb2b9.

In c10145f743694474489fc254a70ef8a0b73eb2b9 the ConnectionContext is added to get the endpoint string but it looks likes that no middleware(HttpOverrides over HttpContext should) is rewriting the RemoteEndpoint field.

Perhaps c10145f743694474489fc254a70ef8a0b73eb2b9 is not needed anymore, I have checked without those changes and the RemoteIpAddress is present (IPV4 over IPV6 format). Am I missing something?

Which project is your bug related to?

-MQTTnet.AspNetCore

To Reproduce

Steps to reproduce the behaviour:

  1. Run MQTTNET over Websockets
  2. Check the Endpoint string in the MQTTnet.Server.MqttConnectionValidatorContext
  3. See proxy IP instead of the X-Forwarded-For IP.

Expected behaviour

The remote endpoint should expose the X-Forwarded-For IP Header address.

Best regards

Jossec101 commented 3 years ago

@xljiulang What do you think?

chkr1011 commented 3 years ago

@JanEggers What do you think about this?

JanEggers commented 3 years ago

I dont know that header thingy or why it should have influence on the remote endpoint property

Jossec101 commented 3 years ago

Basically from what I have seen if you use HttpContext as It was used before the changes introduced c10145f743694474489fc254a70ef8a0b73eb2b9 everything should work fine. In ASP.NET Core if you are behind a reverse proxy there is a HttpOverrides middleware that manages the real ip (https://developer.mozilla.org/es/docs/Web/HTTP/Headers/X-Forwarded-For). That's why I asked @xljiulang the point of that commit instead of using HttpContext class ;).

More info on the docs by MSFT https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-3.1

chkr1011 commented 1 year ago

@xljiulang Is it possible to return to the HttpContext approach instead or does it cause other features to the unusable then?