Production Django use and "real ip"

[Arthur Pemberton]

I have read previous discussions (most recent I could find was Dec 2013  [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the "real" IP address of an HttpRequest. From what I can see, currently there is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django.

However, I do notice that Django acknowledges `X_FORWARDED_HOST`, `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO`  (though SECURE_PROXY_SSL_HEADER).

If there is still opposition to having some built-in handling for `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at least mention the need for the developer to handle this explicitly.

Regards,

Arthur P.

----

[1] https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J

[2] https://docs.djangoproject.com/en/4.1/howto/deployment/

[Adam Johnson]

It's surprisingly complex to interpret x-forwarded-for: https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ . We will never be able to safely add automated handling.

I *guess* we could add a note to the deployment guide like "check your HTTP_X_FORWARDED_FOR setting". I'm concerned it would be a step towards making the guide too long, and filled with irrelevant details. Most sites don't care about recording the user's IP. On those that do, it should be easy enough to discover the setting.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com.

[st...@jigsawtech.co.uk]

As someone whose worked on various projects in different languages over the last 15 years that heavily involved deciphering IP sent in headers to try to determine the "real" IP address of a connection, I would urge caution with anything around determining a "real IP". There is no standard in terms of where to look and what to trust. The X-FORWARDED-FOR is not always right, can easily be spoofed, it can include multiple IPs of which the order is not consistent. Sometimes the left most element is the first and "true IP", sometimes it's the right, sometimes its a value in the middle. It all depends what's included, what appended to the request, what the values are and what you want to trust/ignore. I've seen requests that include internal network IPs, then router/gateway IPs, proxy IPs and load balancers all within that head all in different orders.   It's especially messy when dealing with requests on mobile network where the carrier uses proxies, sometimes 3rd parties, and where your website is hosted behind both load balancers and webserver as each may manipulate the header in different ways.

One of the best packages within the Django eco-system for trying to identify a users actual external IP that I've come across is django-ipware. It allows you to choose the precedence order that matches your use case, yo have private IP prefixes, to configure how many proxies you wish to ignore etc. They also have a handy notice/disclaimer on the subject.

IMO Django core should leave this 3rd party packages and individual deployments to decide and determine what they deem as being the source of the "real IP" for their individual project.

[Arthur Pemberton]

At this point, I'm not even suggesting that Django handle this internally. I'm suggesting that the behaviour/expectation be documented, at least in the deployment guide.

Are there any deployment scenarios where META.REMOTE_ADDR is ever even correct?

Arthur Pemberton

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4f06664d-135e-4eb2-86ec-11eccf4cb495n%40googlegroups.com.

[Adam Johnson]

> Are there any deployment scenarios where META.REMOTE_ADDR is ever even correct?

Yes, when running a WSGI server that faces the internet, with no intermediate proxies.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRYEcNF_j957ii2-wrbcMB1%2BymGQyeoY9PYqAXZGS3qcg%40mail.gmail.com.