Code

Opened 3 years ago

Closed 17 months 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

Description

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.

Attachments (0)

Change History (5)

comment:1 Changed 3 years ago by lrekucki

  • Component changed from Uncategorized to Documentation
  • Easy pickings set
  • Needs documentation set
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 2 years ago by anonymous

  • Resolution set to invalid
  • Status changed from new to closed

django_debug_toolbar is not part of django
setting as invalid

comment:3 Changed 2 years ago by aaugustin

  • Resolution invalid deleted
  • Status changed from closed to reopened

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 17 months ago by peppelorum

  • Owner changed from nobody to peppelorum
  • Status changed from reopened to new

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

comment:5 Changed 17 months ago by peppelorum

  • Resolution set to needsinfo
  • Status changed from new to closed

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.