and clean, pragmatic design. Django was designed to make common Web-development
| 2013-11-12 20:12:12 by Adam Ciarcinski | Files touched by this commit (3) |
Simplified default project and app templates
Improved transaction management
Persistent database connections
Discovery of tests in any test module
Time zone aware aggregation
Support for savepoints in SQLite
BinaryField model field
GeoDjango form widgets
check management command added for verifying compatibility
Model.save() algorithm changed
| 2013-10-28 21:12:40 by Adam Ciarcinski | Files touched by this commit (2) |
Django 1.5.5 fixes a couple security-related bugs and several other bugs in the \
Readdressed denial-of-service via password hashers
Django 1.5.4 imposes a 4096-byte limit on passwords in order to mitigate a \
denial-of-service attack through submission of bogus but extremely large \
passwords. In Django 1.5.5, we’ve reverted this change and instead improved \
the speed of our PBKDF2 algorithm by not rehashing the key on every iteration.
Properly rotate CSRF token on login
This behaviour introduced as a security hardening measure in Django 1.5.2 did \
not work properly and is now fixed.
Fixed a data corruption bug with datetime_safe.datetime.combine.
Fixed a Python 3 incompatability in django.utils.text.unescape_entities().
Fixed a couple data corruption issues with QuerySet edge cases under Oracle and \
Fixed crashes when using combinations of annotate(), select_related(), and only()
| 2013-09-17 21:54:49 by Adam Ciarcinski | Files touched by this commit (2) |
These releases address a denial-of-service attack against Django's \
authentication framework. All users of Django are encouraged to upgrade \
| 2013-09-11 18:50:38 by Adam Ciarcinski | Files touched by this commit (3) |
These releases address a directory-traversal vulnerability in one of Django's \
built-in template tags. While this issue requires some fairly specific factors \
to be exploitable, we encourage all users of Django to upgrade promptly.
| 2013-08-13 19:48:24 by Adam Ciarcinski | Files touched by this commit (3) |
These releases address two cross-site scripting (XSS) vulnerabilities: one in a \
widget used by Django's admin interface, and one in a utility function used to \
validate redirects often used after login or logout.
While these issues are of limited impact and may not effect all Django users, we \
encourage all users to upgrade as soon as possible.
| 2013-04-01 22:52:44 by Adam Ciarcinski | Files touched by this commit (3) |
The biggest fix is for a memory leak introduced in Django 1.5. Under certain \
circumstances, repeated iteration over querysets could leak memory - sometimes \
quite a bit of it. If you'd like more information, the details are in our ticket \
tracker (and in a related issue in Python itself).
If you've noticed memory problems under Django 1.5, upgrading to 1.5.1 should \
fix those issues.
Django 1.5.1 also includes a couple smaller fixes:
* Module-level warnings emitted during tests are no longer silently hidden.
* Prevented filtering on password hashes in the user admin.
| 2013-03-12 21:47:59 by Adam Ciarcinski | Files touched by this commit (3) |
Django 1.5 introduces support for a configurable User model. The basic Django \
User model is still around, of course, but now there's first-class support for \
specifying your own model and having Django's auth system make use of it.
Django 1.5 is the first Django release with support for Python 3 (specifically, \
Python 3.2 and newer). Python 3 support is still considered experimental -- \
largely because it hasn't received as much real-world testing as we'd like -- \
but a Python 3 porting guide is available if you'd like to give it a try, and we \
will be considering Python 3 compatibility bugs to be blockers for future \
Of course, if you're still comfortable with Python 2, Django continues to offer \
support for that just as we always have -- though note that the minimum version \
for Django 1.5 is Python 2.6.5, and Python 2.7.3 or newer is strongly \
Django's documentation has also gotten some pretty significant work; the main \
documentation page has had a bit of a facelift to make things easier to find, \
the existing tutorial got some refurbishing, and several new tutorials -- \
including some more advanced topics, like writing an app you can reuse in \
multiple projects -- have been added. And the documentation for class-based \
views has been significantly expanded, which should make this feature a lot \
easier to understand and take advantage of.
| 2013-02-23 18:00:19 by Adam Ciarcinski | Files touched by this commit (2) |
Security-fix release. Here's a brief summary of each issue and its resolution:
Issue: Host header poisoning: an attacker could cause Django to generate and \
display URLs that link to arbitrary domains. This could be used as part of a \
phishing attack. These releases fix this problem by introducing a new setting, \
ALLOWED_HOSTS, which specifies a whitelist of domains your site is known to \
Important: by default Django 1.3.6 and 1.4.4 set ALLOWED_HOSTS to allow all \
hosts. This means that to actually fix the security vulnerability you should \
define this setting yourself immediately after upgrading.
Issue: Formset denial-of-service: an attacker can abuse Django's tracking of the \
number of forms in a formset to cause a denial-of-service attack. This has been \
fixed by adding a default maximum number of forms of 1,000. You can still \
manually specify a bigger max_num, if you wish, but 1,000 should be enough for \
Issue: XML attacks: Django's serialization framework was vulnerable to attacks \
via XML entity expansion and external references; this is now fixed. However, if \
you're parsing arbitrary XML in other parts of your application, we recommend \
you look into the defusedxml Python packages which remedy this anywhere you \
parse XML, not just via Django's serialization framework.
Issue: Data leakage via admin history log: Django's admin interface could expose \
supposedly-hidden information via its history log. This has been fixed.