Welcome to Django 1.2.4!
\nThis is the fourth “bugfix” release in the Django 1.2 series,\nimproving the stability and performance of the Django 1.2 codebase.
\nWith one exception, Django 1.2.4 maintains backwards compatibility\nwith Django 1.2.3. It also contains a number of fixes and other\nimprovements. Django 1.2.4 is a recommended upgrade for any\ndevelopment or deployment currently using or targeting Django 1.2.
\nFor full details on the new features, backwards incompatibilities, and\ndeprecated features in the 1.2 branch, see the Django 1.2 release notes.
\nThe Django administrative interface, django.contrib.admin, supports\nfiltering of displayed lists of objects by fields on the corresponding\nmodels, including across database-level relationships. This is\nimplemented by passing lookup arguments in the querystring portion of\nthe URL, and options on the ModelAdmin class allow developers to\nspecify particular fields or relationships which will generate\nautomatic links for filtering.
One historically-undocumented and -unofficially-supported feature has\nbeen the ability for a user with sufficient knowledge of a model’s\nstructure and the format of these lookup arguments to invent useful\nnew filters on the fly by manipulating the querystring.
\nHowever, it has been demonstrated that this can be abused to gain\naccess to information outside of an admin user’s permissions; for\nexample, an attacker with access to the admin and sufficient knowledge\nof model structure and relations could construct query strings which –\nwith repeated use of regular-expression lookups supported by the\nDjango database API – expose sensitive information such as users’\npassword hashes.
\nTo remedy this, django.contrib.admin will now validate that\nquerystring lookup arguments either specify only fields on the model\nbeing viewed, or cross relations which have been explicitly\nallowed by the application developer using the preexisting\nmechanism mentioned above. This is backwards-incompatible for any\nusers relying on the prior ability to insert arbitrary lookups.
Ordinarily, a point release would not include new features, but in the\ncase of Django 1.2.4, we have made an exception to this rule.
\nOne of the bugs fixed in Django 1.2.4 involves a set of\ncircumstances whereby a running a test suite on a multiple database\nconfiguration could cause the original source database (i.e., the\nactual production database) to be dropped, causing catastrophic loss\nof data. In order to provide a fix for this problem, it was necessary\nto introduce a new setting – TEST_DEPENDENCIES – that\nallows you to define any creation order dependencies in your database\nconfiguration.
Most users – even users with multiple-database configurations – need\nnot be concerned about the data loss bug, or the manual configuration of\nTEST_DEPENDENCIES. See the original problem report\ndocumentation on controlling the creation order of test\ndatabases for details.
The function-based TEST_RUNNER previously used to execute\nthe GeoDjango test suite, django.contrib.gis.tests.run_gis_tests,\nwas finally deprecated in favor of a class-based test runner,\ndjango.contrib.gis.tests.GeoDjangoTestSuiteRunner, added in this\nrelease.
In addition, the GeoDjango test suite is now included when\nrunning the Django test suite with runtests.py\nand using spatial database backends.