Fixed #15253 -- Added 1.1.3 release notes, and added sections to the 1.2.4 and... (41dc3fc2) · Commits · Dom Sekotill / django

docs/releases/1.1.3.txt

0 → 100644

+50 −0

Original line number	Diff line number	Diff line
		==========================
		Django 1.1.3 release notes
		==========================

		Welcome to Django 1.1.3!

		This is the third "bugfix" release in the Django 1.1 series,
		improving the stability and performance of the Django 1.1 codebase.

		With one exception, Django 1.1.3 maintains backwards compatibility
		with Django 1.1.2. It also contains a number of fixes and other
		improvements. Django 1.1.2 is a recommended upgrade for any
		development or deployment currently using or targeting Django 1.1.

		For full details on the new features, backwards incompatibilities, and
		deprecated features in the 1.1 branch, see the :doc:`/releases/1.1`.

		Backwards incompatible changes
		==============================

		Restricted filters in admin interface
		~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

		The Django administrative interface, django.contrib.admin, supports
		filtering of displayed lists of objects by fields on the corresponding
		models, including across database-level relationships. This is
		implemented by passing lookup arguments in the querystring portion of
		the URL, and options on the ModelAdmin class allow developers to
		specify particular fields or relationships which will generate
		automatic links for filtering.

		One historically-undocumented and -unofficially-supported feature has
		been the ability for a user with sufficient knowledge of a model's
		structure and the format of these lookup arguments to invent useful
		new filters on the fly by manipulating the querystring.

		However, it has been demonstrated that this can be abused to gain
		access to information outside of an admin user's permissions; for
		example, an attacker with access to the admin and sufficient knowledge
		of model structure and relations could construct query strings which --
		with repeated use of regular-expression lookups supported by the
		Django database API -- expose sensitive information such as users'
		password hashes.

		To remedy this, django.contrib.admin will now validate that
		querystring lookup arguments either specify only fields on the model
		being viewed, or cross relations which have been explicitly
		whitelisted by the application developer using the pre-existing
		mechanism mentioned above. This is backwards-incompatible for any
		users relying on the prior ability to insert arbitrary lookups.

docs/releases/1.1.4.txt

+3 −3

Original line number	Diff line number	Diff line
		@@ -8,15 +8,15 @@ This is the fourth "bugfix" release in the Django 1.1 series,
		improving the stability and performance of the Django 1.1 codebase.

		With one exception, Django 1.1.4 maintains backwards compatibility
		with Django 1.1.3, but contain a number of fixes and other
		with Django 1.1.3. It also contains a number of fixes and other
		improvements. Django 1.1.4 is a recommended upgrade for any
		development or deployment currently using or targeting Django 1.1.

		For full details on the new features, backwards incompatibilities, and
		deprecated features in the 1.1 branch, see the :doc:`/releases/1.1`.

		Backwards-incompatible changes in 1.1.4
		=======================================
		Backwards incompatible changes
		==============================

		CSRF exception for AJAX requests
		~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

docs/releases/1.2.4.txt

+36 −2

Original line number	Diff line number	Diff line
		@@ -7,14 +7,48 @@ Welcome to Django 1.2.4!
		This is the fourth "bugfix" release in the Django 1.2 series,
		improving the stability and performance of the Django 1.2 codebase.

		Django 1.2.4 maintains backwards compatibility with Django
		1.2.3, but contain a number of fixes and other
		With one exception, Django 1.2.4 maintains backwards compatibility
		with Django 1.2.3. It also contains a number of fixes and other
		improvements. Django 1.2.4 is a recommended upgrade for any
		development or deployment currently using or targeting Django 1.2.

		For full details on the new features, backwards incompatibilities, and
		deprecated features in the 1.2 branch, see the :doc:`/releases/1.2`.

		Backwards incompatible changes
		==============================

		Restricted filters in admin interface
		~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

		The Django administrative interface, django.contrib.admin, supports
		filtering of displayed lists of objects by fields on the corresponding
		models, including across database-level relationships. This is
		implemented by passing lookup arguments in the querystring portion of
		the URL, and options on the ModelAdmin class allow developers to
		specify particular fields or relationships which will generate
		automatic links for filtering.

		One historically-undocumented and -unofficially-supported feature has
		been the ability for a user with sufficient knowledge of a model's
		structure and the format of these lookup arguments to invent useful
		new filters on the fly by manipulating the querystring.

		However, it has been demonstrated that this can be abused to gain
		access to information outside of an admin user's permissions; for
		example, an attacker with access to the admin and sufficient knowledge
		of model structure and relations could construct query strings which --
		with repeated use of regular-expression lookups supported by the
		Django database API -- expose sensitive information such as users'
		password hashes.

		To remedy this, django.contrib.admin will now validate that
		querystring lookup arguments either specify only fields on the model
		being viewed, or cross relations which have been explicitly
		whitelisted by the application developer using the pre-existing
		mechanism mentioned above. This is backwards-incompatible for any
		users relying on the prior ability to insert arbitrary lookups.

		One new feature
		===============

docs/releases/1.2.5.txt

+1 −1

Original line number	Diff line number	Diff line
		@@ -8,7 +8,7 @@ This is the fifth "bugfix" release in the Django 1.2 series,
		improving the stability and performance of the Django 1.2 codebase.

		With four exceptions, Django 1.2.5 maintains backwards compatibility
		with Django 1.2.4, but contain a number of fixes and other
		with Django 1.2.4. It also contains a number of fixes and other
		improvements. Django 1.2.5 is a recommended upgrade for any
		development or deployment currently using or targeting Django 1.2.

docs/releases/1.3.txt

+30 −0

Original line number	Diff line number	Diff line
		@@ -334,6 +334,36 @@ send back the CSRF token in the custom X-CSRFTOKEN header::
		});


		Restricted filters in admin interface
		~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

		The Django administrative interface, django.contrib.admin, supports
		filtering of displayed lists of objects by fields on the corresponding
		models, including across database-level relationships. This is
		implemented by passing lookup arguments in the querystring portion of
		the URL, and options on the ModelAdmin class allow developers to
		specify particular fields or relationships which will generate
		automatic links for filtering.

		One historically-undocumented and -unofficially-supported feature has
		been the ability for a user with sufficient knowledge of a model's
		structure and the format of these lookup arguments to invent useful
		new filters on the fly by manipulating the querystring.

		However, it has been demonstrated that this can be abused to gain
		access to information outside of an admin user's permissions; for
		example, an attacker with access to the admin and sufficient knowledge
		of model structure and relations could construct query strings which --
		with repeated use of regular-expression lookups supported by the
		Django database API -- expose sensitive information such as users'
		password hashes.

		To remedy this, django.contrib.admin will now validate that
		querystring lookup arguments either specify only fields on the model
		being viewed, or cross relations which have been explicitly
		whitelisted by the application developer using the pre-existing
		mechanism mentioned above. This is backwards-incompatible for any
		users relying on the prior ability to insert arbitrary lookups.

		FileField no longer deletes files
		~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~