Django

Code

Ticket #811 (reopened)

Opened 2 years ago

Last modified 3 weeks ago

[patch] IPv6 address field support

Reported by: mattimustang@gmail.com Assigned to: adrian
Component: Core framework Version: SVN
Keywords: Cc: mir@noris.de, johann.queuniet@gmail.com
Triage Stage: Accepted Has patch: 1
Needs documentation: 1 Needs tests: 1
Patch needs improvement: 1

Description

Hi the attached patch adds a new field called IP6AddressField that allows the entry of IPv6 addresses. It has a validator too called isValidIPAddress6 and I've also added another validator called isValidIPAddress that checks whether an address is IPv4 or IPv6.

Tested on postgres backend.

I initially did this as a replacement for the existing IPAddressField but it breaks backward compatibility because all the non-postgres backends have to have their fields sizes increased.

It's up to you whether you want to do this or not.

Attachments

ip6field.diff (6.3 kB) - added by mattimustang@gmail.com on 11/16/05 00:00:08.
IP6AddressField patch
ipv6field.diff (6.8 kB) - added by mattimustang@gmail.com on 03/12/06 22:57:07.
Updated IPv6 Field patch
ipv6.diff (13.9 kB) - added by Johann Queuniet <johann.queuniet@gmail.com> on 02/02/08 05:43:55.
IPv4/IPv6 field with doc, tests and integration with new/oldforms
ipv6-standalone.diff (16.5 kB) - added by Johann Queuniet <johann.queuniet@gmail.com> on 04/25/08 09:20:57.
Same as the 02/02/08 patch, without IPy

Change History

11/16/05 00:00:08 changed by mattimustang@gmail.com

  • attachment ip6field.diff added.

IP6AddressField patch

02/27/06 13:09:57 changed by jacob

  • status changed from new to closed.
  • resolution set to wontfix.

This looks good, but there are a few things missing:

  • Naming is inconsistant; some places use "ip6" and some "ipv6". I'd prefer "ipv6" (so "IPv6AddressField" and such).
  • There's a bug in the maxlength of IP6AddressField; it should be 39, not 15.

I'm marking wontfix; if you can fix those things with a new patch I'll apply it.

03/12/06 22:57:07 changed by mattimustang@gmail.com

  • attachment ipv6field.diff added.

Updated IPv6 Field patch

03/12/06 23:06:03 changed by mattimustang@gmail.com

  • status changed from closed to reopened.
  • resolution deleted.
  • version set to SVN.
  • component changed from Admin interface to Core framework.

I've cleaned up naming and fixed the bug in the original patch. All fields and validators are clearly marked as being IPv4 or IPv6 now with the exception of the original IPAddressField. Renaming this would break backwards compatibility.

05/26/06 13:46:26 changed by adrian

  • priority changed from normal to low.
  • severity changed from normal to minor.

06/21/06 03:26:32 changed by Seer

Hi all im fine, gl all!

01/17/07 23:16:28 changed by SmileyChris

  • stage changed from Unreviewed to Ready for checkin.

01/25/07 01:03:15 changed by Michael Radziej <mir@noris.de>

  • cc set to mir@noris.de.

01/25/07 08:31:20 changed by russellm

  • needs_better_patch set to 1.
  • stage changed from Ready for checkin to Accepted.
  • needs_tests set to 1.
  • needs_docs set to 1.

This needs a lot more work before it is ready for checkin. There are no tests for the validators, no documentation of the new field, and it doesn't provide any integration with newforms.

07/21/07 09:46:15 changed by Simon G. <dev@simon.net.nz>

  • status changed from reopened to closed.
  • resolution set to wontfix.

Bumping back to wontfix. The current implementation needs a lot of work to get it up to speed, and the fact that this hasn't been touched in over a year suggests that people aren't really crying out for a dedicated field here.

09/29/07 03:47:12 changed by anonymous

seduction Here's my post on how to get laid in the next month or two. This post does not maximize your chances of "getting really good at pickup" - in fact, it does the opposite.

02/02/08 05:43:55 changed by Johann Queuniet <johann.queuniet@gmail.com>

  • attachment ipv6.diff added.

IPv4/IPv6 field with doc, tests and integration with new/oldforms

02/02/08 06:00:31 changed by Johann Queuniet <johann.queuniet@gmail.com>

  • status changed from closed to reopened.
  • resolution deleted.

Since I don't want to see this sinking into oblivion, I'm taking on the task.

Here is a patch I've been using for a few months. It has documentation, integration with new/oldforms and a few tests for the newforms field. IPy is used to validate, since the compressed IPv6 form is near impossible to accurately validate with regexps. I'd be happy if somebody could prove me wrong, of course.

Note that this field can store both IPv4 and IPv6 addresses. Which should be a good thing since I don't think many people are running pure IPv6 stacks out there. But that makes the field name a bit misleading. Any suggestion?

02/02/08 06:01:41 changed by Johann Queuniet <johann.queuniet@gmail.com>

  • cc changed from mir@noris.de to mir@noris.de, johann.queuniet@gmail.com.

02/03/08 18:16:44 changed by Matthew Flanagan <mattimustang@gmail.com>

Hi Johann,

I'm very impressed with your patch. Well done! However I don't think IPy is necessary to perform IPv6 address validation, http://code.djangoproject.com/attachment/ticket/811/ipv6field.diff has regexps that will do that. Not that I object to using IPy but the Django core developers might object to introducing a third-party package.

I'm +1 for merging IPv4 and IPv6 fields into a single field.

(follow-up: ↓ 14 ) 02/03/08 21:18:46 changed by Johann Queuniet <johann.queuniet@gmail.com>

I considered your patch but it actually fails on some edge cases, like 1::2:3:4:5:6:7:8:9 or 0:0:0:0:0:0:0::ffff:1.2.3.4. To elaborate a little on what I said, I don't see any way to *accurately* validate the compressed form with regexp, short from using a separate expression for each possible position of the dual colon shortcut. Nearly times two with the IPv4 compatibility notation. But I'm certainly not a regexp god so yes, feel free to propose a better way and I'll be glad to learn something new :)

Or instead, an alternate solution: getting ride of the regexps altogether and checking if an address converts cleanly to a binary string form. But wouldn't that equals to incude a fair part of IPy in the framework?

I'm also reluctant to introduce yet another third-party dependency, but there is a choice between accuracy and convenience here. Aside from the root of the problem (invalid data), convenience is problematic with PostgreSQL since the inet field will perform a formal validation and either behave eraticaly or throw a ProgrammingException?.

To sum things up, it's either :

  1. allowing invalid data to pass through
  2. using something like fifteen regexps
  3. adding a part of IPy to the framework
  4. asking people to install IPy

If I had to choose, I'd be +1 for the third, -1 for the first and +0 for whatever else. This patch implements the last one since it was the easiest way to get something done. But since it doesn't seem like a trivial issue, we should push this issue on the mailing list. I'm okay to rewrite the validation according to whatever consensus is reached.

(in reply to: ↑ 13 ) 04/10/08 16:08:54 changed by telenieko

Replying to Johann Queuniet <johann.queuniet@gmail.com>:

I considered your patch but it actually fails on some edge cases, like 1::2:3:4:5:6:7:8:9 or 0:0:0:0:0:0:0::ffff:1.2.3.4. To elaborate a little on what I said, I don't see any way to *accurately* validate the compressed form with regexp, short from using a separate expression for each possible position of the dual colon shortcut. Nearly times two with the IPv4 compatibility notation. But I'm certainly not a regexp god so yes, feel free to propose a better way and I'll be glad to learn something new :)

You could always change the "::" to ":0000:" before validation, the address is the same anyway. Or even:

  • Change "::" to ":0000:"
  • Validate
  • If valid, take the original address as the good one

04/10/08 17:30:24 changed by Johann Queuniet <johann.queuniet@gmail.com>

It's a bit more complicated since a :: can act as a shortcut for any number of 0s. But that's part of what I meant by "adding a part of IPy". You can read that as doing some normalization work before the actual validation.

I was in the mood for a first try, so here it is.

def normalize(addr):
    # Some basic error checking
    if addr.count('::') > 2 or addr.find(':::') > -1:
        raise ValueError

    li = addr.split(':')
    nbfull = len([elem for elem in li if elem != ''])

    if nbfull == 8:
        # No need to bother
        return ':'.join(full)
    if nbfull > 8:
        # Has to be invalid anyway
        raise ValueError

    # Begin normalization of ::
    start, end, index = (None, None, 0)
    for elem in li:
        if elem == '':
            if start is None:
                start = index
                end = index
            else:
                end = index
        index += 1
    pad = 8 - nbfull
    if end != start:
        li[start:end-start+1] = ['0'] * pad
    else:
        li[start] = '0'
        if pad > 1:
            li[start:1] = ['0'] * (pad - 1)
    return ':'.join(li)

I'll try to add support for IPv4 and put a new patch together by the week-end. The old one shouldn't apply cleanly anymore since FilePathField? has been added to newforms/fields.py

04/25/08 09:20:57 changed by Johann Queuniet <johann.queuniet@gmail.com>

  • attachment ipv6-standalone.diff added.

Same as the 02/02/08 patch, without IPy

04/25/08 09:31:17 changed by Johann Queuniet <johann.queuniet@gmail.com>

Well, here we are. I added a normalization function in django.utils.http, since I didn't want to create a new module just for that. It should get ride of tricky things like IPv4 mapped addresses and this :: shortcut, without the IPy dependency this time.


Add/Change #811 ([patch] IPv6 address field support)




Change Properties
Action