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 On Sun, Dec 22, 2013 at 7:30 PM, Russell Keith-Magee < [email protected]> wrote: > > On Mon, Dec 23, 2013 at 7:27 AM, Val Neekman <[email protected]> wrote: > >> 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. >> > > 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 %-) > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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. > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CADy_H8ETL8vMvhdPQsczwrU9PHVQKiNdr%2Bb7sidBQRy5GmN4XA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
