setup.py does not require an Internet connection nor setuptools. That was
fixed in [3906]. Updated the minimum Python version as well.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11684 bcc190cf-cafb-0310-a4f2-bffc1f526a37
For the case where someone is using contrib views with custom templates that
they cannot update to use the template tag, it should be possible to use
CsrfResponseMiddleware. This requires that 'csrf_response_exempt' is not
used for the admin views.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11683 bcc190cf-cafb-0310-a4f2-bffc1f526a37
The {% csrf_token %} tag is unable to get its value if a template is
rendered using an inclusion_tag, since that creates a brand new Context,
rather than using the existing one. Since this is a common pattern, and we
need CSRF protection to be as simple and easy as possible, we special case
the csrf_token and copy it from the parent context to the new context.
A more elegant and general solution may appear in future, but this is good
enough for now.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11672 bcc190cf-cafb-0310-a4f2-bffc1f526a37
There is stub code for backwards compatiblity with Django 1.1 imports.
The documentation has been updated, but has been left in
docs/contrib/csrf.txt for now, in order to avoid dead links to
documentation on the website.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11661 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is BACKWARDS INCOMPATIBLE if you were using the completely undocumented moderation view from 1.1. That view's been removed in favor of the admin actions.
Thanks, Thejaswi Puthraya.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11639 bcc190cf-cafb-0310-a4f2-bffc1f526a37
LazyObject called a public method ``get_all_members`` on wrapped objects in
order to allow introspection. This could easily cause name clashes with
existing methods on wrapped objects, and so has been changed to use the
standard methods. This could be slightly backwards-incompatible, in obscure
cases, if the undocumented LazyObject has been used externally.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11636 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Certain email addresses/URLs could trigger a catastrophic backtracking situation, causing 100% CPU and server overload. If deliberately triggered, this could be the basis of a denial-of-service attack.
This security vulnerability was disclosed in public, so we're skipping our
normal security release process to get the fix out as soon as possible.
This is a security related update. A full announcement, as well as backports for the 1.1.X and 1.0.X series will follow.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11603 bcc190cf-cafb-0310-a4f2-bffc1f526a37
