Opened 2 years ago

Last modified 21 months ago

#25456 new Cleanup/optimization

Make GenericIPAddressField normalize IPv4 addresses

Reported by: Frank Owned by: nobody
Component: Database layer (models, ORM) Version: 1.8
Severity: Normal Keywords: ipaddress, ipv4, database, normalization
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (8)

comment:1 Changed 2 years ago by Tim Graham

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?

comment:2 in reply to:  1 Changed 2 years ago by Frank

Replying to 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 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 one. 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.

As to what the proper normalization might be, I think removing the leading zeroes would be enough.

Last edited 2 years ago by Frank (previous) (diff)

comment:3 Changed 2 years ago by Tim Graham

Summary: GenericIPAddressField does not normalize IPv4 addressesMake GenericIPAddressField normalize IPv4 addresses
Triage Stage: UnreviewedAccepted

I was mostly thinking out loud.

comment:4 Changed 2 years ago by KwonHan Bae

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

comment:5 Changed 2 years ago by KwonHan Bae

Ok I sent PR. https://github.com/django/django/pull/5424
please check it

comment:6 Changed 2 years ago by Tim Graham

Has patch: set

comment:7 Changed 2 years ago by Tim Graham

Patch needs improvement: set

comment:8 Changed 21 months ago by Sasha Gaevsky

Has patch: unset
Patch needs improvement: unset

Updated ticket since related PR was closed.

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