Opened 7 years ago

Closed 6 years ago

#16345 closed Bug (needsinfo)

INTERNAL_IPS has issues with IPv6, IPv4

Reported by: narzola@… Owned by: peppelorum
Component: Documentation Version: 1.3
Severity: Normal Keywords: INTERNAL_IPS IPv4 IPv6
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: yes
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no


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 ( runserver ....) but not with the FCGI server ( 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 "" (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:" which was not what I was expecting. It does not match the values I would ordinarily put in INTERNAL_IPS. Putting "::ffff:" 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.


Change History (5)

comment:1 Changed 7 years ago by Łukasz Rekucki

Component: UncategorizedDocumentation
Easy pickings: set
Needs documentation: set
Triage Stage: UnreviewedAccepted

comment:2 Changed 6 years ago by anonymous

Resolution: invalid
Status: newclosed

django_debug_toolbar is not part of django
setting as invalid

comment:3 Changed 6 years ago by Aymeric Augustin

Resolution: invalid
Status: closedreopened

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.

comment:4 Changed 6 years ago by peppelorum

Owner: changed from nobody to peppelorum
Status: reopenednew

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

comment:5 Changed 6 years ago by peppelorum

Resolution: needsinfo
Status: newclosed

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 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.

Note: See TracTickets for help on using tickets.
Back to Top