Getting user's real IP address in Django

[Val Neekman]

Majority of the sites/apps built on Django may require user's real IP address for tracking, prevention, verification and many other reasons.

To get (guess) user's real IP address, one must check few META fields in a particular order to peel off the proxies.

This is what lot of Django developers do already. I call it, "~DRYing the get_real_ip() to death".

With that said, may I purpose to have "django-ipware" blessed and included in core.utils.

Here is the code:

https://github.com/un33k/django-ipware/blob/master/ipware/ip.py

I just want to know if such an API would have a place in core.utils. If so, I'll send a pull request against the proper branch.

Thanks,

Val

[Val Neekman]

correction: 

It should read: "may I propose" instead of "may I purpose".

Thanks,

Val

[Russell Keith-Magee]

core.utils is probably the wrong place -- if we're going to add this sort of thing to core, it wouldn't be as a utility function, but as a readonly property on the request object itself.

I don't recall if this particular idea has been proposed in the past. However I do remember a couple of discussions about the HTTP_X_FORWARDED_FOR and HTTP_X_REAL_IP headers because they can be spoofed by attackers under certain conditions. Therefore, encouraging end-users to rely on these headers (by providing a formal API) is problematic from a security point of view. As I recall, the argument is that any use of these headers must be aware of the local network conditions, and what is (or isn't) guaranteed to be produced by your own web stack, and as a result, we've avoided defining any formal API that uses these headers.

I might be off on the details here; if you do a search of the django-dev archives, you should find any relevant discussions. It would be worth gathering those discussions before proceeding any further.

As an aside, I'd also point out that your logic for private IPs is a little off -- the private network prefixes are 10.*, 172.16.*.* to 172.31.*.*, and 192.168.*.*, representing a class A, B and C network respectively. 127.0.0.1 is a loopback device, not a private network. There's also the fc00::/7 private network block specified by IPv6. 

Yours,

Russ Magee %-)

[Val Neekman]

Russell,

I agree with the spoofing comment you made and it makes sense not to provide a formal API.

I wish there was a middle-ground here, however, at this time, I do not have a solid reason to make a case here. (not yet at least :)

BTW: IP logic was updated as per your feedback.

Thank you.

Val

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq848_z0-JDTBk4EPoXz5DXPgMa2CFdBCFsR%3DQEZhh5%2BEp6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.