PageRenderTime 56ms CodeModel.GetById 24ms RepoModel.GetById 0ms app.codeStats 0ms

/docs/releases/1.2.4.txt

https://code.google.com/p/mango-py/
Plain Text | 86 lines | 68 code | 18 blank | 0 comment | 0 complexity | f54b3b955fc83240ad110c1f52a2a9af MD5 | raw file
Possible License(s): BSD-3-Clause
  1. ==========================
  2. Django 1.2.4 release notes
  3. ==========================
  4. Welcome to Django 1.2.4!
  5. This is the fourth "bugfix" release in the Django 1.2 series,
  6. improving the stability and performance of the Django 1.2 codebase.
  7. With one exception, Django 1.2.4 maintains backwards compatibility
  8. with Django 1.2.3. It also contains a number of fixes and other
  9. improvements. Django 1.2.4 is a recommended upgrade for any
  10. development or deployment currently using or targeting Django 1.2.
  11. For full details on the new features, backwards incompatibilities, and
  12. deprecated features in the 1.2 branch, see the :doc:`/releases/1.2`.
  13. Backwards incompatible changes
  14. ==============================
  15. Restricted filters in admin interface
  16. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  17. The Django administrative interface, django.contrib.admin, supports
  18. filtering of displayed lists of objects by fields on the corresponding
  19. models, including across database-level relationships. This is
  20. implemented by passing lookup arguments in the querystring portion of
  21. the URL, and options on the ModelAdmin class allow developers to
  22. specify particular fields or relationships which will generate
  23. automatic links for filtering.
  24. One historically-undocumented and -unofficially-supported feature has
  25. been the ability for a user with sufficient knowledge of a model's
  26. structure and the format of these lookup arguments to invent useful
  27. new filters on the fly by manipulating the querystring.
  28. However, it has been demonstrated that this can be abused to gain
  29. access to information outside of an admin user's permissions; for
  30. example, an attacker with access to the admin and sufficient knowledge
  31. of model structure and relations could construct query strings which --
  32. with repeated use of regular-expression lookups supported by the
  33. Django database API -- expose sensitive information such as users'
  34. password hashes.
  35. To remedy this, django.contrib.admin will now validate that
  36. querystring lookup arguments either specify only fields on the model
  37. being viewed, or cross relations which have been explicitly
  38. whitelisted by the application developer using the pre-existing
  39. mechanism mentioned above. This is backwards-incompatible for any
  40. users relying on the prior ability to insert arbitrary lookups.
  41. One new feature
  42. ===============
  43. Ordinarily, a point release would not include new features, but in the
  44. case of Django 1.2.4, we have made an exception to this rule.
  45. One of the bugs fixed in Django 1.2.4 involves a set of
  46. circumstances whereby a running a test suite on a multiple database
  47. configuration could cause the original source database (i.e., the
  48. actual production database) to be dropped, causing catastrophic loss
  49. of data. In order to provide a fix for this problem, it was necessary
  50. to introduce a new setting -- :setting:`TEST_DEPENDENCIES` -- that
  51. allows you to define any creation order dependencies in your database
  52. configuration.
  53. Most users -- even users with multiple-database configurations -- need
  54. not be concerned about the data loss bug, or the manual configuration of
  55. :setting:`TEST_DEPENDENCIES`. See the `original problem report`_
  56. documentation on :ref:`controlling the creation order of test
  57. databases <topics-testing-creation-dependencies>` for details.
  58. .. _original problem report: http://code.djangoproject.com/ticket/14415
  59. GeoDjango
  60. =========
  61. The function-based :setting:`TEST_RUNNER` previously used to execute
  62. the GeoDjango test suite, :func:`django.contrib.gis.tests.run_gis_tests`,
  63. was finally deprecated in favor of a class-based test runner,
  64. :class:`django.contrib.gis.tests.GeoDjangoTestSuiteRunner`, added in this
  65. release.
  66. In addition, the GeoDjango test suite is now included when
  67. :ref:`running the Django test suite <running-unit-tests>` with ``runtests.py``
  68. and using :ref:`spatial database backends <spatial-backends>`.