Thanks to Chris Beaven for the initial patch, Fredrik Lundh for the basis
of the parser methodology and Russell Keith-Magee for code reviews.
There are some BACKWARDS INCOMPATIBILITIES in rare cases - in particular, if
you were using the keywords 'and', 'or' or 'not' as variable names within
the 'if' expression, which was previously allowed in some cases.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11806 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 change is backwards incompatible for anyone that is using the named URLs
introduced in [9739]. Any usage of the old admin_XXX names need to be modified
to use the new namespaced format; in many cases this will be as simple as a
search & replace for "admin_" -> "admin:". See the docs for more details on
the new URL names, and the namespace resolution strategy.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11250 bcc190cf-cafb-0310-a4f2-bffc1f526a37
There were a couple of line breaking Unicode characters (\u2028 and
\u2029) that cause Javascript errors, at least in Firefox, if not
escaped. So now we do so. Based on a patch from rleland.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10543 bcc190cf-cafb-0310-a4f2-bffc1f526a37
The max_width argument now passes through FilterExpression which by side-affect
allows float values, but will be truncated.
Thanks obeattie and Eric Holscher for patches.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10352 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This was the (undocumented) behaviour prior to r10118 and now it's back
again. It's neither hard nor harmful to maintain compatibility with the
old ways.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10169 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Most of the hard work for this was done by akaihola.
There are still possibly some problems with the i18n template tags,
since they are written quite differently and a few other bug fixes have
to made before they can be fixed.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10119 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Some template filters and tags understood single-quoted arguments, others
didn't. This makes everything consistent. Based on a patch from akaihola.
Fixed#7295.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10118 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is like "safe", except it operates on the individual elements of a
sequence, rather than treating the whole argument as a string.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9952 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Returning non-ASCII characters from TextNode.__repr__ was causing
problems in the BlockNode.__repr__ method (and probably in other places
we don't know about yet). We now forcibly convert to ascii and replace any
unconvertible characters, rather than returning some moderately
corrupted data in the non-ASCII case.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9757 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Astute readers will notice that the patch originally called this `default`; after consideration I decided that `empty` is a very slightly better color for this particular bikeshed.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9530 bcc190cf-cafb-0310-a4f2-bffc1f526a37
passed in for the connector. This was contrary to what the documentation
for autoescaping said and to what every other filter does with literal
strings as arguments.
This is backwards incompatible for the situation of the literal string
containing one of the five special HTML characters: if you were writing
{{ foo|join:"&" }}, you now have to write {{ foo| join:"&" }}.
Previous behaviour was, as noted, a bug and contrary to what was
documented and expected.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9442 bcc190cf-cafb-0310-a4f2-bffc1f526a37