[Django] #25456: GenericIPAddressField does not normalize IPv4 addresses
Django
-------------------------------------+-------------------------------------
Reporter: frankvdp | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 1.8
(models, ORM) | Keywords: ipaddress, ipv4,
Severity: Normal | database, normalization
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
IPv4 addresses do not get normalized before storing them in the database.
They are stored as Char fields in the database which can lead to both
127.0.0.010 and 127.0.0.10 being stored in the database, although the
value should be unique.
--
Ticket URL: <https://code.djangoproject.com/ticket/25456>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: frankvdp | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 1.8
(models, ORM) |
Keywords: ipaddress, ipv4, | Triage Stage:
database, normalization | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Does the behavior change justify breaking backwards compatibility
(silently changing the input value)? Perhaps so, considering that
PostgreSQL (and its native IP address data type) won't let you store
duplicate values. It reports "Key (ip)=(192.168.1.10) already exists." for
the two addresses you proposed -- so is the proper normalization to remove
the leading zero?
--
Ticket URL: <https://code.djangoproject.com/ticket/25456#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: frankvdp | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 1.8
(models, ORM) |
Keywords: ipaddress, ipv4, | Triage Stage:
database, normalization | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by frankvdp):
Replying to [comment:1 timgraham]:
> Does the behavior change justify breaking backwards compatibility
(silently changing the input value)? Perhaps so, considering that
PostgreSQL (and its native IP address data type) won't let you store
duplicate values. It reports "Key (ip)=(192.168.1.10) already exists." for
the two addresses you proposed -- so is the proper normalization to remove
the leading zero?
To start off, I do not really if you're advocating pro or con :-) But, I
think the current situation is pretty bad. I mean, people can create
models with an addresses which they think have unique values. And in a
sense this also goes against what you expect. You expect an generic ip
address object to be evaluated as such, as an ip address, and not as a
mere string value because it is stored as such. As far as I know, there is
also not mention of this in the current documentation.
So, I also don't think that preserving backwards compatibility
preservation is doing anyone a service in this matter. This might leave
people having unreliable data.
--
Ticket URL: <https://code.djangoproject.com/ticket/25456#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: frankvdp | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 1.8
(models, ORM) |
Keywords: ipaddress, ipv4, | Triage Stage: Accepted
database, normalization |
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* stage: Unreviewed => Accepted
Comment:
I was mostly thinking out loud.
--
Ticket URL: <https://code.djangoproject.com/ticket/25456#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: frankvdp | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 1.8
(models, ORM) |
Keywords: ipaddress, ipv4, | Triage Stage: Accepted
database, normalization |
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by darjeeling):
I think is it possible to add django.utils.ipv4 ?
for ipv6 normalize, django have **django.utils.ipv6.clean_ipv6_address**.
but I think removing leading zero took about 5~6 lines function.
which namespace is proper to add this function? maybe name will be
**normalize_ipv4_address**
--
Ticket URL: <https://code.djangoproject.com/ticket/25456#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: frankvdp | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 1.8
(models, ORM) |
Keywords: ipaddress, ipv4, | Triage Stage: Accepted
database, normalization |
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by darjeeling):
Ok I sent PR. https://github.com/django/django/pull/5424
please check it
--
Ticket URL: <https://code.djangoproject.com/ticket/25456#comment:5>
Django
-------------------------------------+-------------------------------------
Reporter: frankvdp | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 1.8
(models, ORM) |
Keywords: ipaddress, ipv4, | Triage Stage: Accepted
database, normalization |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/25456#comment:6>
Django
-------------------------------------+-------------------------------------
Reporter: frankvdp | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 1.8
(models, ORM) |
Keywords: ipaddress, ipv4, | Triage Stage: Accepted
database, normalization |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/25456#comment:7>
Django
-------------------------------------+-------------------------------------
Reporter: frankvdp | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 1.8
(models, ORM) |
Keywords: ipaddress, ipv4, | Triage Stage: Accepted
database, normalization |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_better_patch: 1 => 0
* has_patch: 1 => 0
Comment:
Updated ticket since related PR was closed.
--
Ticket URL: <https://code.djangoproject.com/ticket/25456#comment:8>
Django
-------------------------------------+-------------------------------------
Reporter: Frank | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Database layer | Version: 1.8
(models, ORM) |
Keywords: ipaddress, ipv4, | Triage Stage: Accepted
database, normalization |
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => fixed
Comment:
Leading zeros are not allowed anymore in IPv4 addresses. Fixed in
e1d787f1b36d13b95187f8f425425ae1b98da188.
--
Ticket URL: <https://code.djangoproject.com/ticket/25456#comment:9>