Django 1.8.10 release notes

Django 1.8.10 fixes two security issues and several bugs in 1.8.9.

Django relies on user input in some cases (e.g. and ) to redirect the user to an “on success” URL. The security check for these redirects (namely django.utils.http.is_safe_url()) considered some URLs with basic authentication credentials “safe” when they shouldn’t be.

Also, if a developer relies on is_safe_url() to provide safe redirect targets and puts such a URL into a link, they could suffer from an XSS attack.

In each major version of Django since 1.6, the default number of iterations for the PBKDF2PasswordHasher and its subclasses has increased. This improves the security of the password as the speed of hardware increases, however, it also creates a timing difference between a login request for a user with a password encoded in an older number of iterations and login request for a nonexistent user (which runs the default hasher’s default number of iterations since Django 1.6).

The new method allows hashers to bridge the runtime gap between the work factor (e.g. iterations) supplied in existing encoded passwords and the default work factor of the hasher. This method is implemented for PBKDF2PasswordHasher and BCryptPasswordHasher. The number of rounds for the latter hasher hasn’t changed since Django 1.4, but some projects may subclass it and increase the work factor as needed.

A warning will be emitted for any third-party password hashers that don’t implement a harden_runtime() method.

• Fixed a crash on PostgreSQL that prevented using TIME_ZONE=None and USE_TZ=False ().
• Added system checks for query name clashes of hidden relationships (#26162).
• Fixed and ArrayField serialization with None values ().
• Reallowed dashes in top-level domain names of URLs checked by URLValidator to fix a regression in Django 1.8 (#26204).
• Prevented ContentTypeManager instances from sharing their cache ().