#10912: Autoescaping variable input in template tags
--------------------------------------+-------------------------------------
Reporter: andrewbadr | Owner: andrewbadr
Status: new | Milestone:
Component: Template system | Version: 1.0
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 1 |
--------------------------------------+-------------------------------------
Changes (by mtredinnick):
* cc: mtredinnick (added)
* needs_better_patch: 0 => 1
* summary: firstof template tag should autoescape variables =>
Autoescaping variable input in template tags
* stage: Unreviewed => Accepted
Old description:
> I'd expect firstof to escape variables.
New description:
(revised description)
When variables are used as input to template tags, we should handle
autoescaping a bit better.
Original description was even shorter:
I'd expect firstof to escape variables.
Comment:
Hmm. This is a bit of a slight change in policy, but not necessarily a bad
one (right now, intentionally, only filters autoescape). However,
1. Import `_render_change_in_context()` smells and not of roses. Needs to
be renamed or not imported or something. That leading underscore is a big
clue.
2. We need something similar to the `autoescape` parameter that is passed
to filters, so that template tags do not autoescape results when they are
being used inside a block that does not do auto-escaping.
I guess template tags know whether they're putting the results into the
context -- which means the output shouldn't be autoescaped, since it will
be autoescaped on output and you don't know at template tag usage time
whether output will involve auto-escaping or not, so it must be delayed
until rendering -- or directly displaying the results? I suspect so, but
that's something to think about and confirm.
What are the backwards compatibility issues here? In particular, right
now, a template tag doesn't have to care about calling `mark_safe()` on
the result, since it just inserts it into the template. If you add the
auto-escaping behaviour at the wrong place, you'll undo that and a lot of
existing template tags will break. That's going to be a little fiddly to
work around.
I'm unenthusiastic about fixing just this single tag, since it does change
the currently consistent behaviour across all template tags. I'm more
enthusiastic about addressing the general issue, but it's a lot more
tricky. I'm really enthusiastic about you doing it, Andrew, since I know
you guys work in the template space a lot, so the results will have some
validity and it means I don't have to work on this (that latter point is
important to me; maybe less so to you).
--
Ticket URL: <http://code.djangoproject.com/ticket/10912#comment:2>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
