django1/docs/releases/1.6.6.txt

==========================
Django 1.6.6 release notes
==========================

*Under development*

Django 1.6.6 fixes several security issues and bugs in 1.6.5.

:func:`~django.core.urlresolvers.reverse()` could generate URLs pointing to other hosts
=======================================================================================

In certain situations, URL reversing could generate scheme-relative URLs  (URLs
starting with two slashes), which could unexpectedly redirect a user  to a
different host. An attacker could exploit this, for example, by redirecting
users to a phishing site designed to ask for user's passwords.

To remedy this, URL reversing now ensures that no URL starts with two slashes
(//), replacing the second slash with its URL encoded counterpart (%2F). This
approach ensures that semantics stay the same, while making the URL relative to
the domain and not to the scheme.

File upload denial-of-service
=============================

Before this release, Django's file upload handing in its default configuration
may degrade to producing a huge number of ``os.stat()`` system calls when a
duplicate filename is uploaded. Since ``stat()`` may invoke IO, this may produce
a huge data-dependent slowdown that slowly worsens over time. The net result is
that given enough time, a user with the ability to upload files can cause poor
performance in the upload handler, eventually causing it to become very slow
simply by uploading 0-byte files. At this point, even a slow network connection
and few HTTP requests would be all that is necessary to make a site unavailable.

We've remedied the issue by changing the algorithm for generating file names
if a file with the uploaded name already exists.
:meth:`Storage.get_available_name()
<django.core.files.storage.Storage.get_available_name>` now appends an
underscore plus a random 7 character alphanumeric string (e.g. ``"_x3a1gho"``),
rather than iterating through an underscore followed by a number (e.g. ``"_1"``,
``"_2"``, etc.).

``RemoteUserMiddleware`` session hijacking
==========================================

When using the :class:`~django.contrib.auth.middleware.RemoteUserMiddleware`
and the ``RemoteUserBackend``, a change to the ``REMOTE_USER`` header between
requests without an intervening logout could result in the prior user's session
being co-opted by the subsequent user. The middleware now logs the user out on
a failed login attempt.

Bugfixes
========

* Corrected email and URL validation to reject a trailing dash
  (:ticket:`22579`).

* Prevented indexes on PostgreSQL virtual fields (:ticket:`22514`).

* Prevented edge case where values of FK fields could be initialized with a
  wrong value when an inline model formset is created for a relationship
  defined to point to a field other than the PK (:ticket:`13794`).

* Restored ``pre_delete``  signals for ``GenericRelation`` cascade deletion
  (:ticket:`22998`).

* Fixed transaction handling when specifying non-default database in
  ``createcachetable`` and ``flush`` (:ticket:`23089`).

* Fixed the "ORA-01843: not a valid month" errors when using Unicode
  with older versions of Oracle server (:ticket:`20292`).

* Restored bug fix for sending unicode email with Python 2.6.5 and below
  (:ticket:`19107`).

* Prevented ``UnicodeDecodeError`` in ``runserver`` with non-UTF-8 and
  non-English locale (:ticket:`23265`).

* Fixed JavaScript errors while editing multi-geometry objects in the OpenLayers
  widget (:ticket:`23137`, :ticket:`23293`).

* Prevented a crash on Python 3 with query strings containing unencoded
  non-ASCII characters (:ticket:`22996`).