0
0
mirror of https://github.com/django/django.git synced 2024-11-25 16:09:27 +01:00
django/docs/releases/1.10.3.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

69 lines
3.0 KiB
Plaintext
Raw Normal View History

2016-10-01 22:11:54 +02:00
===========================
Django 1.10.3 release notes
===========================
*November 1, 2016*
2016-10-01 22:11:54 +02:00
Django 1.10.3 fixes two security issues and several bugs in 1.10.2.
2016-10-01 22:11:54 +02:00
User with hardcoded password created when running tests on Oracle
=================================================================
When running tests with an Oracle database, Django creates a temporary database
user. In older versions, if a password isn't manually specified in the database
settings ``TEST`` dictionary, a hardcoded password is used. This could allow
an attacker with network access to the database server to connect.
This user is usually dropped after the test suite completes, but not when using
the ``manage.py test --keepdb`` option or if the user has an active session
(such as an attacker's connection).
A randomly generated password is now used for each test run.
DNS rebinding vulnerability when ``DEBUG=True``
===============================================
Older versions of Django don't validate the ``Host`` header against
``settings.ALLOWED_HOSTS`` when ``settings.DEBUG=True``. This makes them
vulnerable to a `DNS rebinding attack
<https://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/>`_.
While Django doesn't ship a module that allows remote code execution, this is
at least a cross-site scripting vector, which could be quite serious if
developers load a copy of the production database in development or connect to
some production services for which there's no development instance, for
example. If a project uses a package like the ``django-debug-toolbar``, then
the attacker could execute arbitrary SQL, which could be especially bad if the
developers connect to the database with a superuser account.
``settings.ALLOWED_HOSTS`` is now validated regardless of ``DEBUG``. For
convenience, if ``ALLOWED_HOSTS`` is empty and ``DEBUG=True``, the following
variations of localhost are allowed ``['localhost', '127.0.0.1', '::1']``. If
your local settings file has your production ``ALLOWED_HOSTS`` value, you must
now omit it to get those fallback values.
2016-10-01 22:11:54 +02:00
Bugfixes
========
* Allowed ``User.is_authenticated`` and ``User.is_anonymous`` properties to be
tested for ``set`` membership (:ticket:`27309`).
* Fixed a performance regression when running ``migrate`` in projects
with ``RenameModel`` operations (:ticket:`27279`).
* Added ``model_name`` to the ``allow_migrate()`` calls in ``makemigrations``
(:ticket:`27200`).
* Made the ``JavaScriptCatalog`` view respect the ``packages`` argument;
previously it was ignored (:ticket:`27374`).
* Fixed ``QuerySet.bulk_create()`` on PostgreSQL when the number of objects is
a multiple plus one of ``batch_size`` (:ticket:`27385`).
* Prevented ``i18n_patterns()`` from using too much of the URL as the language
to fix a use case for ``prefix_default_language=False`` (:ticket:`27063`).
* Replaced a possibly incorrect redirect from ``SessionMiddleware`` when a
session is destroyed in a concurrent request with a ``SuspiciousOperation``
to indicate that the request can't be completed (:ticket:`27363`).