Plain Text | 50 lines | 40 code | 10 blank | 0 comment | 0 complexity | cfa2f79006662bd865ff89d50cbad74e MD5 | raw file
1========================== 2Django 1.1.3 release notes 3========================== 4 5Welcome to Django 1.1.3! 6 7This is the third "bugfix" release in the Django 1.1 series, 8improving the stability and performance of the Django 1.1 codebase. 9 10With one exception, Django 1.1.3 maintains backwards compatibility 11with Django 1.1.2. It also contains a number of fixes and other 12improvements. Django 1.1.2 is a recommended upgrade for any 13development or deployment currently using or targeting Django 1.1. 14 15For full details on the new features, backwards incompatibilities, and 16deprecated features in the 1.1 branch, see the :doc:`/releases/1.1`. 17 18Backwards incompatible changes 19============================== 20 21Restricted filters in admin interface 22~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 23 24The Django administrative interface, django.contrib.admin, supports 25filtering of displayed lists of objects by fields on the corresponding 26models, including across database-level relationships. This is 27implemented by passing lookup arguments in the querystring portion of 28the URL, and options on the ModelAdmin class allow developers to 29specify particular fields or relationships which will generate 30automatic links for filtering. 31 32One historically-undocumented and -unofficially-supported feature has 33been the ability for a user with sufficient knowledge of a model's 34structure and the format of these lookup arguments to invent useful 35new filters on the fly by manipulating the querystring. 36 37However, it has been demonstrated that this can be abused to gain 38access to information outside of an admin user's permissions; for 39example, an attacker with access to the admin and sufficient knowledge 40of model structure and relations could construct query strings which -- 41with repeated use of regular-expression lookups supported by the 42Django database API -- expose sensitive information such as users' 43password hashes. 44 45To remedy this, django.contrib.admin will now validate that 46querystring lookup arguments either specify only fields on the model 47being viewed, or cross relations which have been explicitly 48whitelisted by the application developer using the pre-existing 49mechanism mentioned above. This is backwards-incompatible for any 50users relying on the prior ability to insert arbitrary lookups.