Changes between Version 23 and Version 25 of Ticket #28628


Ignore:
Timestamp:
Jan 7, 2022, 5:28:52 AM (3 years ago)
Author:
Mariusz Felisiak
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #28628

    • Property Cc security@… added

  • Ticket #28628 – Description

    v23 v25  
    1111|| django.contrib.humanize.templatetags.humanize || Used in intcomma filter, that formats ints like 3000 as 3,000. \\\\Tested in `tests.humanize_tests.tests.HumanizeTests.test_intcomma`.\\\\Using a more restrictive regex could possibly hurt users. Instead added tests to ensure this works with non-ASCII unicode. ||
    1212|| django.core.validators || (1) Used in URLValidator for `ipv4_re` port component in regex. Being more restrictive to capture valid IPv4 and ports seems useful, and not likely to be a breaking change. **Change** to `[0-9]` for consistency with other parts of the regex.
    13 || django.core.validators ||  (2) Used in `integer_validator` and `validate_integer`. Any number captured by d can be cast to an int and therefore no value is added (and likely users might be hurt) by restricting this to [0-9]). **Do not change**. ||
    14 || django.core.validators || (3) Used in `int_list_validator`, which does not use `int()` → **Change** to `[0-9]`. ||
     13|| django.core.validators ||  (2) Used in `integer_validator`, `validate_integer`, and `int_list_validator`. Any number captured by `\d` can be cast to an int and therefore no value is added (and likely users might be hurt) by restricting this to [0-9]). **Do not change**. ||
    1514|| django.core.management.commands.makemessages || Used to obtain individual decimal components from the gettext version, eg. 1.2.3.\\Changing to a more restrictive regex is unlikely to hurt any users, but doesn't add value either. ||
    1615|| django.core.management.commands.runserver || Used to determine valid IPv4 addresses and valid port numbers. \\WSGI server seems to work fine even if for example 127.0.０.1 (incl a non-ASCII 0) is provided, and it seems the integers are properly cast -- so there would be little advantage to users to change this to a more restrictive regex. ||
Back to Top