INTERNAL_IPS has issues with IPv6, IPv4

[narzola@…]

This may be something that merely needs documenation.

I was having trouble with the django-debug-toolbar on my system. It would work with the debugging server (manage.py runserver ....) but not with the FCGI server (manage.py runfcgi .....). The short version of a long story is that under runserver the call to "request.META.get('REMOTE_ADDR', None)" returns an ip address that looks like "10.3.20.22" (roughly what everyone assumes it will look like). This matches one of the values I have listed in INTERNAL_IPS and the django-debug-toolbar shows up on my pages.

Under flup/FCGI, it returns "::ffff:10.3.20.22" which was not what I was expecting. It does not match the values I would ordinarily put in INTERNAL_IPS. Putting "::ffff:10.3.20.22" in my INTERNAL_IPS caused the django-debug-toolbar to work as expected under flup/FCGI.

It's a totally separate debate on whether or not IPv6 is going to replace IPv4 or when to start preparing for it. The fact is that many Linux systems, mine included, ship with IPv6 turned on and may be returning these funky "::ffff:#.#.#.#" addresses. At the very least, a clear note in the documentation would probably help other developers who are wondering why something that depends on INTERNAL_IPS works in some conditions and not in others or perhaps doesn't work at all. I think a good long term solution would be to have INTERNAL_IPS be an object that can accept IPv4 and IPv6 address and can check to see if REMOTE_ADDR is one of those addresses, reguardless of how REMOTE_ADDR is returned.

I also understand that this little probably is probably not a very high priority, but I hope that when the next developer has this problem, this bug report will come up in their search and at least they won't spend too long figuring it out.

Thanks.

[anonymous]

django_debug_toolbar is not part of django
setting as invalid

[Aymeric Augustin]

I don't think the problem is specific to the debug toolbar; it affects anything that relies on INTERNAL_IPS.

Also, please avoid closing tickets anonymously.

[peppelorum]

This look like enough easy picking for me, so me and @cvitan will try to fix it during the Stockholm Sprint=)

[peppelorum]

We can't replicate the issue reported.

This was our setup to try to reproduce the issue:

• A linux server running both IPv6 and IPv4
• A NGINX that answers on both IPv6 and IPv4 that talks to the FastCGI-server
• A Fastcgi/FLUP running the django instance
• A simple view that just print out the REMOTE_ADDR

We accessed the django site through both the IPv6 and the IPv4 address and in both cases we got the expected IP address (2001:123::1::1::2 for the Ipv6 and 192.168.10.2 for the Ipv4)

To be able to further investigate this the original poster has to provide more info of the setup he or she was using.