diff --git a/docs/howto/error-reporting.txt b/docs/howto/error-reporting.txt index 987a503e950..a9ce798dcaf 100644 --- a/docs/howto/error-reporting.txt +++ b/docs/howto/error-reporting.txt @@ -117,6 +117,8 @@ Filtering error reports Filtering sensitive information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.. currentmodule:: django.views.decorators.debug + Error reports are really helpful for debugging errors, so it is generally useful to record as much relevant information about those errors as possible. For example, by default Django records the `full traceback`_ for the @@ -240,11 +242,13 @@ attribute:: request.exception_reporter_filter = CustomExceptionReporterFilter() ... +.. currentmodule:: django.views.debug + Your custom filter class needs to inherit from :class:`django.views.debug.SafeExceptionReporterFilter` and may override the following methods: -.. class:: django.views.debug.SafeExceptionReporterFilter +.. class:: SafeExceptionReporterFilter .. method:: SafeExceptionReporterFilter.is_active(self, request) diff --git a/docs/releases/1.4-alpha-1.txt b/docs/releases/1.4-alpha-1.txt index cb218ac698e..d47f624f5bb 100644 --- a/docs/releases/1.4-alpha-1.txt +++ b/docs/releases/1.4-alpha-1.txt @@ -337,9 +337,10 @@ docs ` for more information. Error report filtering ~~~~~~~~~~~~~~~~~~~~~~ -Two new function decorators, :func:`sensitive_variables` and -:func:`sensitive_post_parameters`, were added to allow designating the -local variables and POST parameters which may contain sensitive +We added two function decorators, +:func:`~django.views.decorators.debug.sensitive_variables` and +:func:`~django.views.decorators.debug.sensitive_post_parameters`, to allow +designating the local variables and POST parameters that may contain sensitive information and should be filtered out of error reports. All POST parameters are now systematically filtered out of error reports for diff --git a/docs/releases/1.4-beta-1.txt b/docs/releases/1.4-beta-1.txt index 84b1bf6987c..d6700364631 100644 --- a/docs/releases/1.4-beta-1.txt +++ b/docs/releases/1.4-beta-1.txt @@ -375,9 +375,10 @@ docs ` for more information. Error report filtering ~~~~~~~~~~~~~~~~~~~~~~ -Two new function decorators, :func:`sensitive_variables` and -:func:`sensitive_post_parameters`, were added to allow designating the -local variables and POST parameters which may contain sensitive +We added two function decorators, +:func:`~django.views.decorators.debug.sensitive_variables` and +:func:`~django.views.decorators.debug.sensitive_post_parameters`, to allow +designating the local variables and POST parameters that may contain sensitive information and should be filtered out of error reports. All POST parameters are now systematically filtered out of error reports for diff --git a/docs/releases/1.4.8.txt b/docs/releases/1.4.8.txt index bec5a4b7dcb..08dca4065ed 100644 --- a/docs/releases/1.4.8.txt +++ b/docs/releases/1.4.8.txt @@ -1,21 +1,32 @@ ========================== -Django 1.4.7 release notes +Django 1.4.8 release notes ========================== *September 14, 2013* -Django 1.4.8 fixes one security issue present in previous Django releases in +Django 1.4.8 fixes two security issues present in previous Django releases in the 1.4 series. Denial-of-service via password hashers -------------------------------------- -In previous versions of Django no limit was imposed on the plaintext -length of a password. This allows a denial-of-service attack through +In previous versions of Django, no limit was imposed on the plaintext +length of a password. This allowed a denial-of-service attack through submission of bogus but extremely large passwords, tying up server resources performing the (expensive, and increasingly expensive with the length of the password) calculation of the corresponding hash. As of 1.4.8, Django's authentication framework imposes a 4096-byte -limit on passwords, and will fail authentication with any submitted +limit on passwords and will fail authentication with any submitted password of greater length. + +Corrected usage of :func:`~django.views.decorators.debug.sensitive_post_parameters` in :mod:`django.contrib.auth`’s admin +------------------------------------------------------------------------------------------------------------------------- + +The decoration of the ``add_view`` and ``user_change_password`` user admin +views with :func:`~django.views.decorators.debug.sensitive_post_parameters` +did not include :func:`~django.utils.decorators.method_decorator` (required +since the views are methods) resulting in the decorator not being properly +applied. This usage has been fixed and +:func:`~django.views.decorators.debug.sensitive_post_parameters` will now +throw an exception if it's improperly used. diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt index a013665ad34..0bd1da0ef86 100644 --- a/docs/releases/1.4.txt +++ b/docs/releases/1.4.txt @@ -507,10 +507,11 @@ docs ` for more information. Error report filtering ~~~~~~~~~~~~~~~~~~~~~~ -We added two function decorators, :func:`sensitive_variables` and -:func:`sensitive_post_parameters`, to allow designating the local variables -and POST parameters that may contain sensitive information and should be -filtered out of error reports. +We added two function decorators, +:func:`~django.views.decorators.debug.sensitive_variables` and +:func:`~django.views.decorators.debug.sensitive_post_parameters`, to allow +designating the local variables and POST parameters that may contain sensitive +information and should be filtered out of error reports. All POST parameters are now systematically filtered out of error reports for certain views (``login``, ``password_reset_confirm``, ``password_change`` and diff --git a/docs/releases/1.5.4.txt b/docs/releases/1.5.4.txt index 00c56bc5e5e..68deeb5de08 100644 --- a/docs/releases/1.5.4.txt +++ b/docs/releases/1.5.4.txt @@ -1,21 +1,40 @@ ========================== -Django 1.5.3 release notes +Django 1.5.4 release notes ========================== *September 14, 2013* This is Django 1.5.4, the fourth release in the Django 1.5 series. It addresses -one security issue. +two security issues and one bug. Denial-of-service via password hashers -------------------------------------- -In previous versions of Django no limit was imposed on the plaintext -length of a password. This allows a denial-of-service attack through +In previous versions of Django, no limit was imposed on the plaintext +length of a password. This allowed a denial-of-service attack through submission of bogus but extremely large passwords, tying up server resources performing the (expensive, and increasingly expensive with the length of the password) calculation of the corresponding hash. -As of 1.5.3, Django's authentication framework imposes a 4096-byte +As of 1.5.4, Django's authentication framework imposes a 4096-byte limit on passwords, and will fail authentication with any submitted password of greater length. + +Corrected usage of :func:`~django.views.decorators.debug.sensitive_post_parameters` in :mod:`django.contrib.auth`’s admin +------------------------------------------------------------------------------------------------------------------------- + +The decoration of the ``add_view`` and ``user_change_password`` user admin +views with :func:`~django.views.decorators.debug.sensitive_post_parameters` +did not include :func:`~django.utils.decorators.method_decorator` (required +since the views are methods) resulting in the decorator not being properly +applied. This usage has been fixed and +:func:`~django.views.decorators.debug.sensitive_post_parameters` will now +throw an exception if it's improperly used. + +Bugfixes +======== + +* Fixed a bug that prevented a ``QuerySet`` that uses + :meth:`~django.db.models.query.QuerySet.prefetch_related` from being pickled + and unpickled more than once (the second pickling attempt raised an + exception) (#21102). diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt index 2903038b534..ff71c1ce4ec 100644 --- a/docs/releases/1.6.txt +++ b/docs/releases/1.6.txt @@ -783,6 +783,10 @@ using non-string keys in ``request.session``. See the 4096-byte limit on passwords ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.. note:: + This behavior was also added in the Django 1.5.4 and 1.4.8 security + releases. + Historically, Django has imposed no length limit on plaintext passwords. This enables a denial-of-service attack through submission of bogus but extremely large passwords, tying up server resources @@ -792,7 +796,6 @@ of the password) calculation of the corresponding hash. Django now imposes a 4096-byte limit on password length, and will fail authentication with any submitted password of greater length. - Miscellaneous ~~~~~~~~~~~~~ diff --git a/docs/releases/index.txt b/docs/releases/index.txt index c7a557a040d..09467368472 100644 --- a/docs/releases/index.txt +++ b/docs/releases/index.txt @@ -29,6 +29,7 @@ Final releases .. toctree:: :maxdepth: 1 + 1.5.4 1.5.3 1.5.2 1.5.1 @@ -39,6 +40,7 @@ Final releases .. toctree:: :maxdepth: 1 + 1.4.8 1.4.7 1.4.6 1.4.5