determine the "real" ip of a user if possible

[mwjackson]

use ipware for a more sophisticated attempt at the real users source IP address
make Session.ip nullable because its possible that users provide none of the required headers

[coveralls]

Coverage increased (+0.06%) when pulling ccdfc56 on knowsis:ipware into 105ec5c on Bouke:master.

[coveralls]

Coverage increased (+0.06%) when pulling aa35b7f on knowsis:ipware into 105ec5c on Bouke:master.

[Bouke]

Hi @mwjackson thanks for your contribution. Could you explain why the user's IP address might be unknown? AFAIK the REMOTE_ADDR is always available. And secondly, it would rather not depend on external dependencies. However django-ipware looks nice, it should be optional. Not in the sense of adding configuration or something, but something like:

try:
    from ipware.ip import get_real_ip
except ImportError:
    def get_real_ip(request):
        return request.META.get('REMOTE_ADDR', '')

Offcourse, this would also require a small addendum to the documentation. Thanks!

[mwjackson]

Hey there,

Its not so much that REMOTE_ADDR isn't available, but that it can be misleading when behind corporate firewalls, proxies etc.

Good idea to make it optional, I'll amend and re-submit.

[Bouke]

Another issue with django-ipware is there's no guarantee that the headers are being set by proxies. Someone could also spoof the X-Forwarded-For header (or any header used by django-ipware). So using any of those information provided by the client should be a conscious decision of the developer. If the website will run behind a proxy using any of those headers, that'd be fine, otherwise no magic should happen. See also issue #12 and #21 which try to 'address' the same issue.

[mwjackson]

Of course, there is no reliable way to determine an IP address using
headers. Someone could also spoof REMOTE_ADDR just as easily.

The point of ip-ware is to make a better guess than just using 1 header. So
that if the headers are set by nginx, haproxy or whatever proxy, then use
them, otherwise fall back to plain REMOTE_ADDR.
On 1 Oct 2014 07:21, "Bouke Haarsma" notifications@github.com wrote:

Another issue with django-ipware is there's no guarantee that the headers
are being set by proxies. Someone could also spoof the X-Forwarded-For
header
http://security.stackexchange.com/questions/8721/benefits-of-identifying-clients-based-upon-the-x-forwarded-for-or-similar-http
(or any header used by django-ipware
https://github.com/un33k/django-ipware/blob/566ba5574469754df8dc407ccbfcd686f88e394e/ipware/defaults.py#L8-L16).
So using any of those information provided by the client should be a
conscious decision of the developer. If the website will run behind a proxy
using any of those headers, that'd be fine, otherwise no magic should
happen. See also issue #12
#12 and #21
#21 which try to
'address' the same issue.

—
Reply to this email directly or view it on GitHub
#20 (comment)
.

[Bouke]

Someone could also spoof REMOTE_ADDR just as easily.

I don't think one could "just as easily" spoof one's IP address. Once you're doing that, you can only send, but not receive. You would have no way of knowing your Django's session ID, other than receiving. In order to receive, the webserver must know your real IP address.

Setting a header is rather straight-forward, and blind-sightedly relying on them is certainly not good. Come to think of it, looking up the user's IP address is highly dependent on your installation. Is there some proxy modifying the request? So, which header / environment variable will it use? The way django-ipware works is that it'll just grab anything from the request, regardless of it being provided by the user or the proxy.

I'm inclined to reject this proposal and instead solely rely on REMOTE_ADDR instead. This wouldn't mean that looking up other headers is possible at all. Just include a middleware that sets REMOTE_ADDR to the designated header. In the case you don't care which header is used (strongly discouraged), write a middleware that uses django-ipware.