Default escaping -- again!
Luke Plant
committed. And I've had an idea that I don't think came up, that I
thought was perhaps worth throwing into the mix.
Basically, {{ }} does escaping automatically, and {! !} doesn't.
Of course, we can then argue about whether it should be the other way
around, or flame each other about favourite punctuation marks, but you
get the idea. (IMHO, I think using ! for strings that could be
dangerous is a fabulous idea and anyone says otherwise is a luser ;-)
Advantages: it's dead simple, and, as presented, it solves the escaping
problem without making it (much) harder to handle strings that
shouldn't be escaped.
Main disadvantage: as presented, it's backwards incompatible.
Sorry for not being around much, btw, been a bit busy.
Luke
--
I teleported home one night
With Ron and Sid and Meg,
Ron stole Meggie's heart away
And I got Sidney's leg
(THHGTTG)
Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
Deryck Hodge
>
> Unless I missed something, the default escaping proposal hasn't been
> committed. And I've had an idea that I don't think came up, that I
> thought was perhaps worth throwing into the mix.
>
> Basically, {{ }} does escaping automatically, and {! !} doesn't.
>
But how is remembering to do {! var !} any easier than remembering {{
var|escape }}? I think that's the issue most people had, that
escaping is easy to overlook.
Not that I have any problem per se with your use of punctuation. ;-) :-)
Cheers,
deryck
--
Deryck Hodge http://www.devurandom.org/
Developer, Naples News http://www.naplesnews.com/
Samba Team http://www.samba.org/
Luke Plant
> But how is remembering to do {! var !} any easier than remembering {{
> var|escape }}? I think that's the issue most people had, that
> escaping is easy to overlook.
In my proposal, if you do {{ var }} you are covered, so you don't have
to remember anything. It's if you know that it *shouldn't* be escaped
that you have to remember to do {! var !}. I guess if it were the
other way around there wouldn't be much advantage. Of course, if you
get them mixed up...
Tom Tobin
> committed. And I've had an idea that I don't think came up, that I
> thought was perhaps worth throwing into the mix.
>
> Basically, {{ }} does escaping automatically, and {! !} doesn't.
From what I recall of conversations on the subject, default behavior
will not be changed to auto-escape. Auto-escaping, under whatever
proposal is accepted, will require some form of action to enable.
Deryck Hodge
>
> > But how is remembering to do {! var !} any easier than remembering {{
> > var|escape }}? I think that's the issue most people had, that
> > escaping is easy to overlook.
>
> In my proposal, if you do {{ var }} you are covered, so you don't have
> to remember anything. It's if you know that it *shouldn't* be escaped
> that you have to remember to do {! var !}. I guess if it were the
> other way around there wouldn't be much advantage. Of course, if you
> get them mixed up...
>
As I did... :-) But that's my fault for reading too quickly. My appologies.
As Tom said, default auto-escaping is the issue, of which I am one
non-supporter for reasons cited so well by others previously.
cheers,
Simon Willison
> From what I recall of conversations on the subject, default behavior
> will not be changed to auto-escape. Auto-escaping, under whatever
> proposal is accepted, will require some form of action to enable.
I like to think that's not set in stone yet. There's a lot of
opposition to having it on by default, but I'm hoping there's a
chance that people might start to change their minds once they've had
the opportunity to try it out. I'm not going to push the point until
it's ready to try though, and I think that arguing the point is
pointless without running code to act as an example.
(Malcolm Tredinnick's patch looks like a really great bash at this;
it's great that someone's taking the initiative and hammering out
some code).
Cheers,
Simon
Jacob Kaplan-Moss
> (Malcolm Tredinnick's patch looks like a really great bash at this;
> it's great that someone's taking the initiative and hammering out
> some code).
FYI, Malcom, Adrian and I spent some time talking this over today at
OSCON. Expect to see some follow-up soon.
Jacob
Ahmad Alhashemi
that this is a good idea, even if HTML is, incidentally, the most
commonly used language in templates, for the time being.
Simon Willison
Here's an idea I don't think anyone has brought up yet: what if
escaping was on by default for templates ending in .html and off by
default for templates ending in .txt?
I'm not sure how I feel about this, seeing as we only recently made
it so you had to specify the file extension. It seems to fit quite
nicely though. That said, there may be problems getting it to work
with alternative template sources.
Cheers,
Simon
Jeremy Dunck
> Here's an idea I don't think anyone has brought up yet: what if
> escaping was on by default for templates ending in .html and off by
> default for templates ending in .txt?
Make a setting to turn define the default, and if the setting's not
there, auto-escape.
Anyone that doesn't want it can just turn it off by defining the setting.
AUTO_ESCAPE_TEXT = _True_|False
Deryck Hodge
> Make a setting to turn define the default, and if the setting's not
> there, auto-escape.
> Anyone that doesn't want it can just turn it off by defining the setting.
>
> AUTO_ESCAPE_TEXT = _True_|False
This is the exact scenario that should be avoided most, which came up
last time this was discussed. What if I have all the apps on my site
without auto-escaping by default, but another person's app, which I
want to incorporate into my site, expects auto-escaping?
Sure, there are work arounds, but a default setting that can be
toggled on or off is not a sane solution.
Cheers,
Bill de hÓra
> On 7/27/06, Jeremy Dunck <jdu...@gmail.com> wrote:
>> Make a setting to turn define the default, and if the setting's not
>> there, auto-escape.
>> Anyone that doesn't want it can just turn it off by defining the setting.
>>
>> AUTO_ESCAPE_TEXT = _True_|False
>
> This is the exact scenario that should be avoided most, which came up
> last time this was discussed. What if I have all the apps on my site
> without auto-escaping by default, but another person's app, which I
> want to incorporate into my site, expects auto-escaping?
>
> Sure, there are work arounds, but a default setting that can be
> toggled on or off is not a sane solution.
Scope it per template:
{% extends "base_generic.html" %}
{% escape %}
This lets people who want auto-escaping, have it, without typing in
"|escape" everywhere or screwing things up site wide with globals.
Alternative, do it in the view code:
def detail(request, poll_id):
p = get_object_or_404(Poll, pk=poll_id)
return render_to_response('detail.html', {'poll': p}, escape=True)
cheers
Bill
James Bennett
> Scope it per template:
>
> {% extends "base_generic.html" %}
> {% escape %}
>
> This lets people who want auto-escaping, have it, without typing in
> "|escape" everywhere or screwing things up site wide with globals.
Yeah. AFAIK that's pretty much how Malcolm's patch handles it (with an
'autoescape' tag to turn it on)
> Alternative, do it in the view code:
Eh. Not crazy about that; escaping belongs in the template layer, and
having it able to be set from anywhere else gets us into nastiness as
people try to figure out, in the template, whether the view turned
escaping on or not.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
Todd O'Bryan
different tags for escaping vs. auto-escaping.
What if we deprecated {{ }} and replaced it with an escape tag and a
raw tag? It would keep backward compatibility, but would encourage
people to use escaped strings unless they have a reason to use raw
ones. I suppose we don't really have to deprecate it, but just
discourage its use.
{! !} seems perfect for raw, because the exclamation points emphasize
that something bad could happen.
{$ $} could be used for escaping, with the $'s designed to remind
people of environment variables. This would be tag people are
encouraged to use unless they need raw HTML text.
Todd
Simon Willison
On 28 Jul 2006, at 13:06, Todd O'Bryan wrote:
> What if we deprecated {{ }} and replaced it with an escape tag and a
> raw tag? It would keep backward compatibility, but would encourage
> people to use escaped strings unless they have a reason to use raw
> ones. I suppose we don't really have to deprecate it, but just
> discourage its use.
>
> {! !} seems perfect for raw, because the exclamation points emphasize
> that something bad could happen.
>
> {$ $} could be used for escaping, with the $'s designed to remind
> people of environment variables. This would be tag people are
> encouraged to use unless they need raw HTML text.
The above is nice and simple, but it only solves a subset of the
problem that auto_escaping is designed to solve. The missing
component is filters: for filters to be truly chainable, they need an
awareness of if their input is escaped or not. The 'unorderedlist' vs
'escaped_unorderedlist' discussion from a while back is a good
example of that. This is covered in more detail in the proposal on
the wiki.
Cheers,
Simon
Jeremy Dunck
>
> On 7/27/06, Jeremy Dunck <jdu...@gmail.com> wrote:
> > Make a setting to turn define the default, and if the setting's not
> > there, auto-escape.
> > Anyone that doesn't want it can just turn it off by defining the setting.
> >
> > AUTO_ESCAPE_TEXT = _True_|False
>
> This is the exact scenario that should be avoided most, which came up
> last time this was discussed. What if I have all the apps on my site
> without auto-escaping by default, but another person's app, which I
> want to incorporate into my site, expects auto-escaping?
So, I'll hold my water until we hear back from Jacob et al.
Ahmad Alhashemi
> Here's an idea I don't think anyone has brought up yet: what if
> escaping was on by default for templates ending in .html and off by
> default for templates ending in .txt?
This does seem like a practical solution. But I think that it gives
more meaning to template file names than they should have. It will make
excerpts of Django templates impossible to interpret without knowing
the name of the file. I can see the topic of the IRC channel becoming:
"please specify the filename of any template code you paste here".
Besides, it will force people to change template filenames if they
don't want auto-escaping. This can cause trouble, especially if you are
referring to your template names in other places (extends, includes and
views).
Jeremy Dunck wrote:
> Make a setting to turn define the default, and if the setting's not
> there, auto-escape.
> Anyone that doesn't want it can just turn it off by defining the setting.
>
> AUTO_ESCAPE_TEXT = _True_|False
This will couple templates to the project. This is the #1 reason why
PHP suck.
Todd O'Bryan wrote:
> {! !} seems perfect for raw, because the exclamation points emphasize
> that something bad could happen.
>
> {$ $} could be used for escaping, with the $'s designed to remind
> people of environment variables. This would be tag people are
> encouraged to use unless they need raw HTML text.
This again is putting too much emphasis on HTML as the language used in
templates. It reminds me with the special treatment Perl gives to
regular expressions.
Bill de hÓra wrote:
> Scope it per template:
>
> {% extends "base_generic.html" %}
> {% escape %}
>
> This lets people who want auto-escaping, have it, without typing in
> "|escape" everywhere or screwing things up site wide with globals.
This is nearly perfect for my taste. The only thing is to make it just
a bit more generic like this:
{% autofilter escape %}
This will specify that the escape filter will be applied automatically
to all variables. It is just as easy to use, it is not specific to HTML
and it can be used in other useful contexts, like for escaping in a
JavaScript template. It doesn't break backward's compatibility. It
doesn't force you to do anything you don't want to.
We can even provide the {! !} tags to mean "do not apply auto filter".
Then I can immagine some files starting with:
{% autofilter javascript_escape %}
Then escaping and the {! !} will work perfecly well in a JavaScript
template.
Deryck Hodge
> So, I'll hold my water until we hear back from Jacob et al.
>
I didn't mean to seem like I was saying "so shut up already". :-)
This just keeps coming up with the same arguments for and against over
and over again. My apologies if I seemed harsh.
I, too, am looking forward to seeing what Jacob et al
propose/implement. Real code is always better then real ideas.
Steven Armstrong
<snip>
>
> Bill de hÓra wrote:
>> Scope it per template:
>>
>> {% extends "base_generic.html" %}
>> {% escape %}
>>
>> This lets people who want auto-escaping, have it, without typing in
>> "|escape" everywhere or screwing things up site wide with globals.
>
> This is nearly perfect for my taste. The only thing is to make it just
> a bit more generic like this:
>
> {% autofilter escape %}
>
> This will specify that the escape filter will be applied automatically
> to all variables. It is just as easy to use, it is not specific to HTML
> and it can be used in other useful contexts, like for escaping in a
> JavaScript template. It doesn't break backward's compatibility. It
> doesn't force you to do anything you don't want to.
>
> We can even provide the {! !} tags to mean "do not apply auto filter".
> Then I can immagine some files starting with:
>
> {% autofilter javascript_escape %}
>
> Then escaping and the {! !} will work perfecly well in a JavaScript
> template.
>
nice! +1
Malcolm Tredinnick
> Deryck Hodge wrote:
> > On 7/27/06, Jeremy Dunck <jdu...@gmail.com> wrote:
> >> Make a setting to turn define the default, and if the setting's not
> >> there, auto-escape.
> >> Anyone that doesn't want it can just turn it off by defining the setting.
> >>
> >> AUTO_ESCAPE_TEXT = _True_|False
> >
> > This is the exact scenario that should be avoided most, which came up
> > last time this was discussed. What if I have all the apps on my site
> > without auto-escaping by default, but another person's app, which I
> > want to incorporate into my site, expects auto-escaping?
> >
> > Sure, there are work arounds, but a default setting that can be
> > toggled on or off is not a sane solution.
>
> Scope it per template:
>
> {% extends "base_generic.html" %}
> {% escape %}
>
> This lets people who want auto-escaping, have it, without typing in
> "|escape" everywhere or screwing things up site wide with globals.
This is exactly how it works (modulo slightly different terminology).
See the original explanation in
http://groups.google.com/group/django-developers/browse_thread/thread/7caeb86c04b81f10/931d5e0f65cc354b?lnk=gst&rnum=1#931d5e0f65cc354b
The discussion Jacob, Adrian and I had yesterday did not come up with
any conclusions that were vastly different from the initial patch I
wrote. So it's a pretty good reference for the next few days until I
finish it.
> Alternative, do it in the view code:
>
> def detail(request, poll_id):
> p = get_object_or_404(Poll, pk=poll_id)
> return render_to_response('detail.html', {'poll': p}, escape=True)
We are trying to keep the auto-escaping environment completely within
the control of the template author. This person may very well not be the
person writing the view and should have to go and track down said person
to find out the context they are operating in. Similarly, keeping this
control out of the views help template reuse with different views.
For similar reasons -- and to avoid the counter-problem that the view
author has to know everything about the template -- we have ensured that
if a view passes in a safe string (one that requires no further
escaping) to a template and the template author applies the escape tag
to it, it will not be further escaped (there will be a force_escape
filter for when that is required).
Regards,
Malcolm
Jacob Kaplan-Moss
> Here's an idea I don't think anyone has brought up yet: what if
> escaping was on by default for templates ending in .html and off by
> default for templates ending in .txt?
>
> I'm not sure how I feel about this, seeing as we only recently made
> it so you had to specify the file extension. It seems to fit quite
> nicely though. That said, there may be problems getting it to work
> with alternative template sources.
*This* is worth thinking about more completely... very intriguing!
Jacob
Adrian Holovaty
> escaping was on by default for templates ending in .html and off by
> default for templates ending in .txt?
I'm not keen on coupling the template filename to the template
contents. Altering behavior based on the name of a template seems a
bit too magical.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Roland van Laar
On Jul 28, 2006, at 9:21 PM, Adrian Holovaty wrote:
>
> On 7/27/06, Simon Willison <swil...@gmail.com> wrote:
>> Here's an idea I don't think anyone has brought up yet: what if
>> escaping was on by default for templates ending in .html and off by
>> default for templates ending in .txt?
>
> I'm not keen on coupling the template filename to the template
> contents. Altering behavior based on the name of a template seems a
> bit too magical.
Would it be better to couple it with the mimetype? A text/plain should
by default not be excaped.
My $ 0.02
Roland
>
> Adrian
James Bennett
> Would it be better to couple it with the mimetype? A text/plain should
> by default not be excaped.
What would be *best* is for there to be no magical implied
escaping/unescaping of anything, only explicit escaping/unescaping
based on a template tag.
SmileyChris
> On 7/28/06, Roland van Laar <the_m...@myrealbox.com> wrote:
> > Would it be better to couple it with the mimetype? A text/plain should
> > by default not be excaped.
>
> What would be *best* is for there to be no magical implied
> escaping/unescaping of anything, only explicit escaping/unescaping
> based on a template tag.
Like this:
http://code.djangoproject.com/wiki/AutoEscape%20alternative ?
Alan Green
> We are trying to keep the auto-escaping environment completely within
> the control of the template author.
Thanks.
This is really important as even a plain old HTML file can require
several different kinds of escaping in different parts (e.g inside an
href attribute, in Javascript) and some parts that you never want to
escape (e.g {{ form.field }}). I'd hate to have to be switching back
and forth between the template and the view code each time there's a
little tweak to the UI.
I'm looking forward to seeing how it works in my templates,
Alan.
--
Alan Green
al...@bright-green.com - http://bright-green.com