Disabling autoescaping when calling render_to_string
Darryl Ross
I'm using the templating system to send emails, but the templates are
being autoescaped. Now, I know I can use {% autoescape off %} in my
template files, but the logic I use to build the email body is similar to:
template_name = 'emails/generic.txt'
if condition1:
template_name = 'emails/template1.txt'
elif condition2:
template_name = 'emails/template2.txt'
elif condition3:
template_name = 'emails/template3.txt'
body = render_to_string(template_name, context_vars)
The reason I'm shying away from using the autoescape tag is that it
breaks DRY in my mind, but it also means that there's more places to
miss it and it also seems unnecessary as this is for plain text emails.
I've been reading through the code in django/template to try and work
out how the auto-escaping is done, but I have to admit defeat, I can't
follow it through at the moment.
So my question is, is there an argument which will disable
auto-escaping? If not, would there be some merit to adding some
functionality that allows this, either as an argument or perhaps to make
the auto-escaping only auto-escape if the template filename ends in '.html'?
Regards
Darryl
James Bennett
> So my question is, is there an argument which will disable auto-escaping?
> If not, would there be some merit to adding some functionality that allows
> this, either as an argument or perhaps to make the auto-escaping only
> auto-escape if the template filename ends in '.html'?
No, and probably not. One of the key things about Django's
autoescaping is that, since it applies in the template, you can look
at the template to find out what's going on. Introducing lots of other
places where you'd need to look, transforming it from "look at the
template to see if the autoescape tag or the safe filter are used" to
"look at the template, then look at this argument, then look at this
setting, then..." would be a disaster.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Darryl Ross
I can see your point, but I disagree for two reasons.
The first is that to find out what template is being used, you most
likely need to look in the view for the urls file, so having an argument
there is obvious. The auto-escaping based on file extension was just
something I was throwing out there and I don't think it's a particularly
good idea myself.
The second reason is that the auto-escaping was, correct me if I'm
wrong, to help prevent cross-site vulnerabilities caused by browsers
interpreting HTML. There are other uses for the templating besides
generating content for browsers, such as sending emails and generating
other files, like CSV or XML.
Regards
Darryl
Malcolm Tredinnick
On Sun, 2008-04-27 at 12:37 +0930, Darryl Ross wrote:
> James Bennett wrote:
> > On Sat, Apr 26, 2008 at 9:38 PM, Darryl Ross <dar...@afoyi.com> wrote:
> >> So my question is, is there an argument which will disable auto-escaping?
> >> If not, would there be some merit to adding some functionality that allows
> >> this, either as an argument or perhaps to make the auto-escaping only
> >> auto-escape if the template filename ends in '.html'?
> >
> > No, and probably not. One of the key things about Django's
> > autoescaping is that, since it applies in the template, you can look
> > at the template to find out what's going on. Introducing lots of other
> > places where you'd need to look, transforming it from "look at the
> > template to see if the autoescape tag or the safe filter are used" to
> > "look at the template, then look at this argument, then look at this
> > setting, then..." would be a disaster.
>
> I can see your point, but I disagree for two reasons.
>
> The first is that to find out what template is being used, you most
> likely need to look in the view for the urls file, so having an argument
> there is obvious.
No, it isn't obvious. Somebody writing a template should know exactly
how it is going to be parsed. That person isn't necessarily the person
writing the view (code). To keep the designer/developer separation
clean, we made auto-escaping controllable via the template.
> The second reason is that the auto-escaping was, correct me if I'm
> wrong, to help prevent cross-site vulnerabilities caused by browsers
> interpreting HTML. There are other uses for the templating besides
> generating content for browsers, such as sending emails and generating
> other files, like CSV or XML.
Which is why the autoescaping template tag exists. It enables you to
disable things.
You are bringing up points that were hashed out again and again on the
developers list leading up to autoescaping being committed. Yes, there
are differing opinions. There's no way to reach unanimous consensus here
and we picked one, quite usable, method for the implementation.
Malcolm
--
Always try to be modest and be proud of it!
http://www.pointy-stick.com/blog/
Darryl Ross
>>>> So my question is, is there an argument which will disable auto-escaping?
Nevermind me, the version of code I was reading on my dev machine
through was older than I thought, pre-autoescaping. I did an update and
there is now an optional argument to the Context() constructor which
does what I want.
> No, it isn't obvious. Somebody writing a template should know exactly
> how it is going to be parsed. That person isn't necessarily the person
> writing the view (code). To keep the designer/developer separation
> clean, we made auto-escaping controllable via the template.
Which is all well and good for a "website" designer. Someone who is
writing templates for emails might not be expecting HTML escaping, but
anyway.
> You are bringing up points that were hashed out again and again on the
> developers list leading up to autoescaping being committed. Yes, there
> are differing opinions. There's no way to reach unanimous consensus here
> and we picked one, quite usable, method for the implementation.
Sorry, my searching in google hadn't turned up any archives of any
conversations like that.
By the way, I'm not against the auto-escaping, I just think there are
situations (such as generation of email messages) where it is not
required. I'm glad that the option to turn it off is actually there.
Thanks for your hard work guys, it is appreciated. Part of my reason for
going through this is to try to get some better idea of the codebase so
I can contribute a bit more.
Cheers
Darryl