#16302: Ensure contrib (namely comments) is IPv6 capable
-------------------------------------+----------------------------------
Reporter: toofishes | Owner: nobody
Type: Bug | Status: new
Milestone: 1.4 | Component: contrib.comments
Version: SVN | Severity: Normal
Resolution: | Keywords: ipv6
Triage Stage: Accepted | Has patch: 1
Needs documentation: 1 | Needs tests: 1
Patch needs improvement: 1 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+----------------------------------
Changes (by erikr):
* cc: eromijn@… (added)
* keywords: => ipv6
Comment:
It would look like there is a backwards compatibility issue, but I don't
believe there is, because the existing code is just as broken as the new
code would be when using the old database field.
Regarding storage: both IPAddressField and GenericIPAddressField use
either postgres' `inet` or a `char(15)`/`char(39)` for storing. So an IPv4
address stored by IPAddressField can be read by GenericIPAddressField.
Considering the current case:
* Comment comes from an IPv4 address in the current code: no problems
* Comment comes from an IPv6 address in the current code: silently
truncated to 15 characters, or complete failure if the database does not
do silent truncation (there is no model validation for IPAddressField, so
it is not detected as invalid).
In other words: the comment framework is broken when a client comments
from an IPv6 address.
Considering this, there is no change in behavior if we use a
GenericIPAddressField with a char(15) backing it. IPv4 just works, IPv6 is
truncated, either silently or loudly. However, with the `unpack_ipv4`
parameter, IPv6-mapped IPv4 addresses would work even with a char(15)
backend - whereas they break now with IPAddressField.
So, updating this even if the database field is not changed will not
introduce any additional failures, and even avoid a failure that currently
exists. Obviously the best for the user is to also update the database
field appropriately. Therefore, changing the field is not breaking
backwards compatibility.
Regarding the patch: I agree this needs tests, I think the field change is
fine. `REMOTE_ADDR` is exactly one of the cases I had in mind when I wrote
the `unpack_ipv4` parameter.
--
Ticket URL: <https://code.djangoproject.com/ticket/16302#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
