the behaviour of django for fields that contain html markup ("<" ...) is wrong, at least in version 0.91.
First, the admin pages do not html escape these. There might be corner cases when this is intended, but it seems very dangerous.
Second, regarding Template, I think the default not to html escape variable nodes is not the right one. I think the normal case should be to escape these, unless otherwise noted.
I've written a derived HTMLTemplate class for myself that uses a different VariableNode to achieve this effect, and attached this if you're interested.
Now, did I miss something and is this already fixed? Should this be treated differently? How do other people handle this?
If you're positive about my way I'll polish my stuff up for inclusion with the contribs.
On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote:
> Now, did I miss something and is this already fixed? Should this be > treated differently? How do other people handle this?
The problem in the admin was fixed in [1982]: http:// code.djangoproject.com/changeset/1982; in your own templates you'll want to use the "escape" filter (http://www.djangoproject.com/ documentation/templates/#escape) on any potentially dangerous entries.
Why not do it for all variables? At times you want to pass chunks of HTML into a template that get displayed raw. I don't think the behavior you suggest should be default, but do you have any ideas on how to make it optional? It certainly could be useful in certain cases.
Jacob Kaplan-Moss wrote: > On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote: >> Now, did I miss something and is this already fixed? Should this be >> treated differently? How do other people handle this?
> The problem in the admin was fixed in [1982]: http:// > code.djangoproject.com/changeset/1982; in your own templates you'll > want to use the "escape" filter (http://www.djangoproject.com/ > documentation/templates/#escape) on any potentially dangerous entries.
> Why not do it for all variables? At times you want to pass chunks of > HTML into a template that get displayed raw. I don't think the > behavior you suggest should be default,
maybe a stupid question, but why not?
for me it seems that most of time it's fine to escape the text, so for me it would make sense to have it on by default...and for the cases when i wan to enter raw data into the page template, we could have an 'unescape' filter..we could call it 'raw' for example..
Gábor Farkas wrote: > Jacob Kaplan-Moss wrote: >> On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote: >>> Now, did I miss something and is this already fixed? Should this be >>> treated differently? How do other people handle this?
>> The problem in the admin was fixed in [1982]: http:// >> code.djangoproject.com/changeset/1982; in your own templates you'll >> want to use the "escape" filter (http://www.djangoproject.com/ >> documentation/templates/#escape) on any potentially dangerous entries.
>> Why not do it for all variables? At times you want to pass chunks of >> HTML into a template that get displayed raw. I don't think the >> behavior you suggest should be default,
> maybe a stupid question, but why not?
<snip>
after i sent my response, i've read the original posters mail (i should have done it at the beginning) and i see that i'm just repeating his words.i'm sorry.
Jacob Kaplan-Moss wrote: > The problem in the admin was fixed in [1982]: http:// > code.djangoproject.com/changeset/1982;
thanks (and sorry--I'll start using the svn then)
> in your own templates you'll > want to use the "escape" filter (http://www.djangoproject.com/ > documentation/templates/#escape) on any potentially dangerous entries.
> Why not do it for all variables? At times you want to pass chunks of > HTML into a template that get displayed raw. I don't think the > behavior you suggest should be default, but do you have any ideas on > how to make it optional? It certainly could be useful in certain > cases.
Thanks for your input!
The problem I see is that it's potentially dangerous to use the non- escaped strings, and I'd prefer to have the safe thing as default (and, isn't it the most common case?)
My idea to make it optional is included (exerimental!) in the attachment to my original mail. In summary:
- provide an additional template class (I called it HTMLTemplate, but I'm not sure if this is a good name), together with loader support.
- there's also a subclass of unicode, currently called HTMLEscapedString. If you have something that is already in html format and should not be escaped, use this class.
- the template (or rather the associated HTMLVariableNode) will apply the template filter if the context entry is not already an instance of HTMLEscapedString
I'd like to see some comments from more seasoned django developers and whether you feel this is the wrong way or if you are interested in this some way or the other.
Jacob Kaplan-Moss wrote: > Why not do it for all variables? At times you want to pass chunks of > HTML into a template that get displayed raw. I don't think the > behavior you suggest should be default, but do you have any ideas on > how to make it optional?
the standard solution is to use a wrapper for strings that you *don't* want escaped. see e.g. the section on "HTML templates" on this page:
On 3/3/06, fred...@pythonware.com <fred...@pythonware.com> wrote:
> Jacob Kaplan-Moss wrote:
> > Why not do it for all variables? At times you want to pass chunks of > > HTML into a template that get displayed raw. I don't think the > > behavior you suggest should be default, but do you have any ideas on > > how to make it optional?
> the standard solution is to use a wrapper for strings that you > *don't* want escaped. see e.g. the section on "HTML templates" > on this page:
The other problem is that not everyone wants the same escape. For instance, there are those of us that {% load markup %} and then |restructuredtext (or |markdown or |textile) just about everything, and auto-HTML escape could certainly cause havoc here.
-- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler
Max Battcher wrote: > On 3/3/06, fred...@pythonware.com <fred...@pythonware.com> wrote: >> Jacob Kaplan-Moss wrote:
>>> Why not do it for all variables? At times you want to pass chunks of >>> HTML into a template that get displayed raw. I don't think the >>> behavior you suggest should be default, but do you have any ideas on >>> how to make it optional? >> the standard solution is to use a wrapper for strings that you >> *don't* want escaped. see e.g. the section on "HTML templates" >> on this page:
> The other problem is that not everyone wants the same escape. For > instance, there are those of us that {% load markup %} and then > |restructuredtext (or |markdown or |textile) just about everything, > and auto-HTML escape could certainly cause havoc here.
those filters could first de-html-escape the content.
i understand that it seems silly for this configuration. i only wanted to demonstrate that even with auto-html-escaping you can still use those markups fine.
I've thought about this a bit more; lots of good points have been raised. What I'd like to do would be to add a new tag that takes care of auto-escaping variables used within it. Something like::
{% autoescape %} Any {{ variables }} used within this {{ block }} will be automatically {{ escaped }} {% endautoescape %}
Max Battcher wrote: > > the standard solution is to use a wrapper for strings that you > > *don't* want escaped. see e.g. the section on "HTML templates" > > on this page:
> The other problem is that not everyone wants the same escape. For > instance, there are those of us that {% load markup %} and then > |restructuredtext (or |markdown or |textile) just about everything, > and auto-HTML escape could certainly cause havoc here.
such filters should of course wrap their return values before returning them.
> I've thought about this a bit more; lots of good points have been > raised. What I'd like to do would be to add a new tag that takes > care of auto-escaping variables used within it. Something like::
> {% autoescape %} > Any {{ variables }} used within this {{ block }} will be > automatically {{ escaped }} > {% endautoescape %}
> I've thought about this a bit more; lots of good points have been > raised. What I'd like to do would be to add a new tag that takes > care of auto-escaping variables used within it. Something like::
> {% autoescape %} > Any {{ variables }} used within this {{ block }} will be > automatically {{ escaped }} > {% endautoescape %}
> How does that sound?
Not quite enough IMHO.
I strongly agree with some of the other posters in this thread that any kind of output in an HTML-template should be HTML-escaped by default. Values that contain markup that should not be escaped should be flagged explicitly.
In Trac 0.9.3 we added exactly this kind of behavior to greatly eliminate the risk for XSS vulnerabilities. See:
When the template engine sees a value that is a str/unicode, it gets escaped. If it gets a value that's an instance of the "Markup" class, it gets passed through as-is.
Adding such behavior to the Django template processor would be great. It's *much* easier to forget to escape something than to forget to flag it as not-needing-escaping.
