On Jul 6, 2006, at 4:14 AM, Simon Willison wrote:
> I just got back from EuroPython, and one of the hot topics there was
> templating systems. One thing that caught me by surprise when
> discussing this issue is how Django is actually the exception rather
> than the norm in terms of the escaping
On 6 Jul 2006, at 05:09, SmileyChris wrote:
> Does the template source *need* to provide information on what is
> escaped or not?
>
> The view is handling a lot of the output format anyway, I personally
> don't see a problem with looking there to see how a template is being
> escaped.
>
> Then a
Hi Malcom,
Thanks for the comments.
Does the template source *need* to provide information on what is
escaped or not?
The view is handling a lot of the output format anyway, I personally
don't see a problem with looking there to see how a template is being
escaped.
Then again, I guess escaping
On Wed, 2006-07-05 at 18:50 -0700, SmileyChris wrote:
[...]
> My proposal is that we don't use a {% autoescape on/off %} block tag or
> a new |raw filter in the template source at all, but rather always use
> the view to set it the auto-escaping status.
> The developer wanting to use autoescaping
> Yes, Django should be accessible to newbies, but newbie-friendliness
> needs to be balanced against the needs of experienced web developers
> (who likely already know all about XSS).
To exume an old horse and continue beating it, experienced web
developers may know all about XSS, but they will
James Bennett wrote:
> On 6/22/06, waylan <[EMAIL PROTECTED]> wrote:
> > Some are suggesting that this text should be escaped before being
> > written to the db. It is true that the above text should be rendered as
> > follows in html/xml documents:
>
> I don't think we should escape before stori
Michael Radziej wrote:
[snip]
>
> I assume this is about Jacob's proposal, and it's handling this
> case correctly. Let's go through the steps he specified:
>
[snip]
Whether it is handling this case correctly or not, it still needs to be
escaped in an html or xml template, but not in a plain text
Hi Jacob!
>
> On Jun 21, 2006, at 12:13 PM, Simon Willison wrote:
>> Rather than directly accessing GET and POST data
>> you do it through some mechanism that /guarantees/ the format of the
>> data returned - and raises an exception if it can't make that
>> guarantee. There is no possible way of
Hi,
waylan wrote:
> I've been following this thread since the get-go with interest, but am
> a first time commenter here. Although I think the devs have a clear
> picture, I get the feeling that some participants in this discussion
> are geting input validation and output escaping confused which
On 6/22/06, waylan <[EMAIL PROTECTED]> wrote:
> Some are suggesting that this text should be escaped before being
> written to the db. It is true that the above text should be rendered as
> follows in html/xml documents:
I don't think we should escape before storing. I think we should
*validate*
I've been following this thread since the get-go with interest, but am
a first time commenter here. Although I think the devs have a clear
picture, I get the feeling that some participants in this discussion
are geting input validation and output escaping confused which is
generating lots of unnes
On 6/22/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> I disagree that it's easy to write that kind of validator function -
> and I think trying to do so is a mistake. What if I want to post a
> comment on a forum like this?
Then you'd get caught by the validator.
Thinking about the implication
Hi Jacob,
Jacob Kaplan-Moss wrote:
> 2. Methods exist somewhere to "translate" untrusted strings into
> "normal" strings given a particular format. Like Simon, I'm not sure
> how to spell this, but I'm sure a good syntax could be found.
I'm not sure I missed a point; is this, for html, the
Hi, all. Yes, I like this much better, too.
> 1. request.GET['whatever'] returns a ``untrusted_string`` object, not
> a regular string
>
> 2. Methods exist somewhere to "translate" untrusted strings into
> "normal" strings given a particular format. Like Simon, I'm not sure
> how to spell this,
On 22 Jun 2006, at 04:50, James Bennett wrote:
>> following that, I think Django should, of the two options, cover the
>> majority, which I believe is "escape by default" and allow {%
>> autoescape off %}. For the sake of security, I'm really hoping to see
>> escaping automatically turned on.
>
On 22 Jun 2006, at 08:48, James Bennett wrote:
> For given values of "validate", yes. It is, however, easy to write
> validator functions which will reject anything that looks like HTML,
> and HTML is the most important threat.
I disagree that it's easy to write that kind of validator function -
On 6/22/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Now, I don't like to put the whole burden into the input validation,
And nobody's really suggesting that we should; we already provide a
template filter for sanitizing on output, and a block tag for doing
the same seems like a decent idea.
On 6/22/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Now, come on, that's a completely different thing than auto-escaping
> of variables in the template. I had no idea php is/was *that* brain-
> dead (*shiver*)
The problem of suddenly having to figure out ways to tell whether
you're dealing w
Hey,
First, let me note that we're discussing one aspect of Django and
whether or not there is a sensible way to harden it agains XSS
exploits. It is not whether this or the other way is better ...
Now, I don't like to put the whole burden into the input validation,
since I believe
* Ther
Am 22.06.2006 um 06:54 schrieb James Bennett:
>
> On 6/21/06, Tyson Tate <[EMAIL PROTECTED]> wrote:
>> Oh - I haven't heard of the magic_quotes fiasco. Do you have any
>> links or more information about this? If it blew up for the PHP
>> folks, I think I'd be prone to changing my position on the
On 6/21/06, Tyson Tate <[EMAIL PROTECTED]> wrote:
> Oh - I haven't heard of the magic_quotes fiasco. Do you have any
> links or more information about this? If it blew up for the PHP
> folks, I think I'd be prone to changing my position on the issue.
The magic_quotes setting in PHP is a "feature"
On Jun 21, 2006, at 8:50 PM, James Bennett wrote:
> Has the world honestly learned not one single solitary thing form
> PHP's magic_quotes fiasco? Autoescaping all output by default is
> something that is unequivocally not acceptable.
Oh - I haven't heard of the magic_quotes fiasco. Do you have a
If you don't ever want to display the html then it shouldn't be
stored in the first place. The escaping/removing should be done when
processing the input. What's better:
1. escaping/removing when the data is saved (one time occasion) or
2. escaping/removing each time the data is used (infinit
On 6/21/06, Tyson Tate <[EMAIL PROTECTED]> wrote:
> Then again, how often do you *want* to allow your users to put HTML
> and JS in and allow it to be executed? Not often, I imagine.
This depends completely on the type of application. Some applications
will have very little HTML input by users, b
On Jun 21, 2006, at 6:57 PM, Jacob Kaplan-Moss wrote:
> Yes, I agree -- I've never been against a template tag which does
> autoescape because that's still leaving power in the hands of the
> template authors.
Then again, how often do you *want* to allow your users to put HTML
and JS in and al
On Jun 21, 2006, at 9:29 PM, SmileyChris wrote:
> Out of interest, have you (both Jacob and anyone else involved in this
> discussion) seriously tried an auto-escaping templating system and had
> a problem with it opposing your needs?
At the risk of turning this into a war stories thread, I've ha
Hi Jacob,
On Jun 21, 2006, at 5:16 PM, SmileyChris wrote:
> > Having used TAL a lot (like KID, automatically escapes), I did not
> > actually find this annoying.
Jacob Kaplan-Moss wrote:
> I really wish there was a way of saying this that didn't make me
> sound like a jerk... but:
>
> If y
On Jun 21, 2006, at 8:35 PM, Todd O'Bryan wrote:
> Does there seem to be consensus out there among web frameworks about
> whether escape=default, raw=exception or raw=default,
> escape=exception?
Not really sure, myself -- my impression is that most web frameworks
don't think about XSS all th
On Jun 21, 2006, at 6:41 PM, Jacob Kaplan-Moss wrote:
> There's
> no right and wrong here, there's just what "fits" with the rest of
> the framework, and encapsulating a distrust of the developer into
> this framework doesn't feel right.
Does there seem to be consensus out there among web framew
I have to agree with these comments.
get the crap out at the 'input'/validation level.. once it has the
database/rendering stage it is too late.
while this submission isn't perfect, this is what I did to protect
against my own laziness on externally facing apps.
http://svn.zyons.python-hosti
On Jun 21, 2006, at 3:31 PM, Jacob Kaplan-Moss wrote:
> [...]
> Another place to start solving the XSS problem is at the input level;
> a policy of "don't trust data from the web" makes a lot more sense to
> me than one of "don't trust the template author".
Modded "+5 Insightful" :) I can attest
On Jun 21, 2006, at 5:16 PM, SmileyChris wrote:
> Having used TAL a lot (like KID, automatically escapes), I did not
> actually find this annoying.
I really wish there was a way of saying this that didn't make me
sound like a jerk... but:
If you like TAL better, use it.
Again, I'm not
Hi,
How about adding a command to django-admin.py that scans all the
templates of the project and enabled apps and gives you a list of
templates that have unescaped values in them, maybe even display the
tags/lines concerned. IMHO this could be very valueable info for a
developer.
Rudolph
--~-
On Jun 21, 2006, at 12:13 PM, Simon Willison wrote:
> Rather than directly accessing GET and POST data
> you do it through some mechanism that /guarantees/ the format of the
> data returned - and raises an exception if it can't make that
> guarantee. There is no possible way of invalid data ending
James Bennett wrote:
> Security by annoyance is security that people learn to hate and turn
> off as soon as they can, so in the end it doesn't really make them any
> more secure than they were before.
Having used TAL a lot (like KID, automatically escapes), I did not
actually find this annoying.
On 6/21/06, oefe <[EMAIL PROTECTED]> wrote:
>
> Agreed.
> To prevent XSS vulnerabilities because someone forgot to specify the
> escaping rule, I would suggest that templates should, maybe even must
> specify their escaping. For example, require each template to contain a
> special {% autoescape
Hi,
I'm new to this group, so let me give you a little background about
myself:
I'm not a professional web developer (I'm writing Windows apps), but
have done a few private web projects for fun and to learn new things. I
recently redsigned a TurboGears project in Django, and liked the
experience
On 21 Jun 2006, at 17:48, James Bennett wrote:
> And while we're at it, let's get serious about input handling. The
> first thing which occurs to me is to add a 'hasNoHTML' validator in
> django.core.validators; possibly this would be accompanied by a
> boolean 'allows_html' argument to TextFiel
And just to clarify, when I talk about implementing the escaping
system, I mean a block tag which escapes everything inside itself as
appropriate. Nothing more, nothing less.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
--~--~-~--~~---
The more I think about it, the more I find I have two objections to
the auto-escaping stuff.
1. A philosophical objection. One thing Django does, and does pretty
well IMHO, is encourage best practices. Pretty much every aspect of
Django, from the overall architecture of the framework to the worki
[EMAIL PROTECTED] wrote:
> noone said "forbid nothing". i said "you don't need to forbid all '<'s",
> which is what you proposed was a problem with a data validation take.
My point was that your approach restricts user input. "<" was a
simple example for this.
Not that, first, it's not really s
noone said "forbid nothing". i said "you don't need to forbid all '<'s",
which is what you proposed was a problem with a data validation take.
you would obviously forbid html in an HTMLSafeCharField, which does limit
user's input. i'm just saying that in the vast, vast, vast majority of
form in
"My vote is for escaping being off unless explicitly turned on, and for it being turned on in the template."
My thoughts exactly, my templates are the places that define the output of my applications. I can see the benefits of people been able to define how escaping happens _in the template_, _if
[EMAIL PROTECTED] wrote:
> not true. no browser interprets a single "<" as a tag unless it has a
> valid tag name (and company) and closing ">" directly after it. only the
> most rudimentary implementations would blindly strip "<"s without looking
> at their context.
So, how exactly would you v
not true. no browser interprets a single "<" as a tag unless it has a
valid tag name (and company) and closing ">" directly after it. only the
most rudimentary implementations would blindly strip "<"s without looking
at their context.
(and they would be wrong anyway - consider )
> Derek Hoy w
Derek Hoy wrote:
> On 6/20/06, SmileyChris <[EMAIL PROTECTED]> wrote:
>> But it is an escaping issue.
>
> Isn't the most common use case for this the problem of people entering
> bad stuff into a form? In which case, regarding it as a validation
> issue seems good to me.
This is the perl-taint-a
On 6/20/06, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> But it is an escaping issue.
Isn't the most common use case for this the problem of people entering
bad stuff into a form? In which case, regarding it as a validation
issue seems good to me.
For example, I used Webmin a few days ago to fix s
Hi Andrew,
it appears to be decided that Adrian won't include auto-escaping,
but I'd like to round-up this discussion so that we can gather
the pros and cons somewhere. I bet that this discussion will pop
up again ...
For as much as I see, the discussion looks pretty thorough. I
acknowledge your
Michael Radziej wrote:
>
> IMO, the point of auto-escaping is that the template author should not have
> to worry about
> the origin of the string, but about how he uses it. The origin of the string
> in the
> context can change, just for an example. Or are we talking about different
> meanings
Simon Willison wrote:
> On 20 Jun 2006, at 16:25, James Bennett wrote:
>
> > Security by annoyance is security that people learn to hate and turn
> > off as soon as they can, so in the end it doesn't really make them any
> > more secure than they were before.
>
> Agreed - which is why I want to tr
Simon Willison wrote:
>
> On 19 Jun 2006, at 21:00, [EMAIL PROTECTED] wrote:
>
>> anyway, i suppose i will wait for you to elaborate on your
>> reasoning in
>> the wiki this evening. :)
>
> I've written up a proposal for how we can implement auto escaping
> while hopefully keeping most peo
On 6/20/06, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On 20 Jun 2006, at 16:25, James Bennett wrote:
>
> > Security by annoyance is security that people learn to hate and turn
> > off as soon as they can, so in the end it doesn't really make them any
> > more secure than they were before.
>
>
On 20 Jun 2006, at 16:25, James Bennett wrote:
> Security by annoyance is security that people learn to hate and turn
> off as soon as they can, so in the end it doesn't really make them any
> more secure than they were before.
Agreed - which is why I want to try it in a branch and see if it's
On 6/20/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I haven't used the magical versions of Django, but I regard the magic that
> has magically imported models a different thing. In every framework things
> happen automatically, and just calling it "bad magic" is something that
> might result
Adrian Holovaty wrote:
> On 6/20/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
>>
>> You're against automatically quoting your data in the database driver?
>> Let's rip it out, bad magic that munges your data behind your back.
>>
>
> I figured somebody might bring up this example, but it isn't
On 20 Jun 2006, at 15:11, Michael Radziej wrote:
> But, looking at the recent bugs in the Admin:
>
> 2006, __str__() output not escaped in breadcrumbs and filters
> 2152, username was not escaped
>
> Perhaps neither of this would be fixed with auto-escaping. But I
> want to
> emphasize that bu
On 6/20/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> You're against automatically quoting your data in the database driver?
> Let's rip it out, bad magic that munges your data behind your back.
>
I figured somebody might bring up this example, but it isn't quite
analogous. With a database
Adrian Holovaty wrote:
> On 6/20/06, Simon Willison <[EMAIL PROTECTED]> wrote:
>> I've written up a proposal for how we can implement auto escaping
>> while hopefully keeping most people happy:
>>
>> http://code.djangoproject.com/wiki/AutoEscaping
>
> I've gotta say, I don't like the concept of a
On 6/20/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I've gotta say, I don't like the concept of auto-escaping on by
> default. I'd rather not have the framework automatically munging my
> data behind my back: it'd be a case of the same type of magic that we
> removed in the magic-removal bran
On 6/20/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> I've written up a proposal for how we can implement auto escaping
> while hopefully keeping most people happy:
>
> http://code.djangoproject.com/wiki/AutoEscaping
I've gotta say, I don't like the concept of auto-escaping on by
default. I'd r
Hey Andrew!
adurdin wrote:
> Michael Radziej wrote:
>> adurdin wrote:
>>> Having the context aware of the primary escaping needs of the output is
>>> a nice idea, but as James Bennett pointed out, the template is what
>>> should be making the decision.
>> I still don't see why. The programmer who
Michael Radziej wrote:
>
> adurdin wrote:
>
> You could simply encode the URL, as you currently need to do anyway, and then
> mark it as escaped.
True.
> > Having the context aware of the primary escaping needs of the output is
> > a nice idea, but as James Bennett pointed out, the template is
On 20 Jun 2006, at 12:15, Michael Radziej wrote:
> Perhaps it's also a good idea to add an attribute `raw` to the
> class `escaped`, so that
> you can always access the raw string when it is necessary. In some
> circumstances, such
> as when you pass a complete html table in the context, thi
On 20 Jun 2006, at 12:02, Todd O'Bryan wrote:
> Couldn't we do something less invasive/complicated?
>
> How about
>
> {{ var }}
>
> by default escapes the contents (in other words, the very first
> filter called on a variable is escape, by default) and
>
> {{ var|raw }}
>
> skips the call to escap
Hi,
I thought a little bit about your remarks and I think all your problems can be
solved.
Perhaps it's also a good idea to add an attribute `raw` to the class `escaped`,
so that
you can always access the raw string when it is necessary. In some
circumstances, such
as when you pass a complet
Hey. We came up with this independently. It must be a good idea. :-)
Todd
On Jun 20, 2006, at 5:50 AM, adurdin wrote:
> Simon Willison wrote:
>> I've written up a proposal for how we can implement auto escaping
>> while hopefully keeping most people happy:
>>
>> http://code.djangoproject.com/wi
Couldn't we do something less invasive/complicated?
How about
{{ var }}
by default escapes the contents (in other words, the very first
filter called on a variable is escape, by default) and
{{ var|raw }}
skips the call to escape?
It breaks backwards compatibility, but maybe there's a way
adurdin wrote:
>
> The main drawback I see with this is that the behaviour of
> {{mylist|count}} is not obviously unescaped.
I meant {{mylist|length}}, of course.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Dj
Simon Willison wrote:
> I've written up a proposal for how we can implement auto escaping
> while hopefully keeping most people happy:
>
> http://code.djangoproject.com/wiki/AutoEscaping
A very nice solution, with a good method of automatically flagging
things as escaped or not; but it seems to m
Simon Willison wrote:
> I've written up a proposal for how we can implement auto escaping
> while hopefully keeping most people happy:
>
> http://code.djangoproject.com/wiki/AutoEscaping
GoodStuff! (tm)
Michael
--~--~-~--~~~---~--~~
You received this message
On 19 Jun 2006, at 21:00, [EMAIL PROTECTED] wrote:
> anyway, i suppose i will wait for you to elaborate on your
> reasoning in
> the wiki this evening. :)
I've written up a proposal for how we can implement auto escaping
while hopefully keeping most people happy:
http://code.djangoproject
[EMAIL PROTECTED] wrote:
> that's why i suggest looking at this as a data validation issue. (not
> simply as escaping) we do lots of validation in the model already.
But it is an escaping issue.
There's nothing wrong with allowing html to be entered in (for example)
a comment field. It should
> I'm not keen on escaping being controlled by the model - escaping
> should be a template-level decision as that's when you decide what
> format is being output (plain text email / HTML / XML / LaTeX for PDF
> conversion etc).
>
> I played around with some proof of concepts over the weekend and I
On 19 Jun 2006, at 20:18, [EMAIL PROTECTED] wrote:
> The biggest downside is if you want valid HTML data stored for one
> output
> type and escaped for another. But this is not a scenario I've ever
> seen
> in the real world, and regardless is easily worked around with simply
> returning to
To better detail the "in the model" idea:
An additional field type would be added, extending CharField, called say
"HTMLSafeField". It would strip/escape/convert/reject invalid strings
both when being set and when being read. Otherwise it would behave just
like a CharField.
The key is not to t
On 6/16/06, Christopher Lenz <[EMAIL PROTECTED]> wrote:
> To reiterate: templates shouldn't need to care about escaping. Django
> *in particular* uses an intentionally dumbed down template system
> that is supposed to be easy for non-programmers, which includes the
> notion that little mistakes in
Brilliant, Christopher. This is exactly the solution I'd be pleased
with!
We still have the problem of invalidating every single template written
so far in Django, however...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Am 14.06.2006 um 21:08 schrieb Jacob Kaplan-Moss:
[snip]
> Given that, I think the best idea is still using a block tag::
>
> {% escape %}
> {{ var }}
> {% endescape %}
I feel this is inelegant and insufficient. Back when this topic was
raised last time, I chimed in with a r
On 14/06/06, oggie rob <[EMAIL PROTECTED]> wrote:
> So I think {% auto_escape_on %} or {% auto_escape_off %} are better
> options (depending on consensus to which should be the default).
I'm kind of +1 for leaving it off by default - I'm not keen on data
getting munged behind my back.
And as for
On 6/15/06, James Bennett <[EMAIL PROTECTED]> wrote:
> I don't know... memories are stirring of my PHP days and the horror of
> magic_quotes...
As long as the data is only escaped on final output (and here escaping
should actually be intelligent as to whether it's outputting html, or
some mime-en
On 6/15/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> What would you rather have:
> "Help, help! How do I turn off escaping?"
I don't know... memories are stirring of my PHP days and the horror of
magic_quotes...
--
"May the forces of evil become confused on the way to your house."
-- George
gabor wrote:
> is it true, that people usually forget to escape dangerous variables?
>
>
> a) if no (people do not forget):
> means people are already using 'escape' when needed. in this case, this
> block-level tag is a welcome addition, because it makes it
> simpler/more-convenient to toggle esc
gabor wrote:
> my guess is (b)
I think (b) is pretty much a given. Looking back in the developers
group history, I see this is a recurring problem that seems to keep
getting put in the "too hard" basket.
See:
http://groups.google.com/group/django-users/browse_thread/thread/21da889ecb9c63dd/145e3
Jacob Kaplan-Moss wrote:
> Hi folks --
>
> So the benefits of automatic escaping are pretty obvious --
> protection from XSS attacks -- but I'm wary of a few details in the
> existing proposals.
>
>
i completely agree that before doing such a global change, all
consequences will have to
Hi folks --
So the benefits of automatic escaping are pretty obvious --
protection from XSS attacks -- but I'm wary of a few details in the
existing proposals.
First, escaping everything by default complete breaks every existing
template. That's not necessarily a complete deal-breaker, but
Hi,
Derek Anderson mentioned the need for different kinds of escaping. So
maybe the syntax should be more something like:
{% autoescape xml on %}
and
{% autoescape javascript on %}
Rudolph
--~--~-~--~~~---~--~~
You received this message because you are subscr
On 6/14/06, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On 14 Jun 2006, at 17:19, oggie rob wrote:
>
> > a) The ever-present argument about file extensions & template syntax
> > (that we seemed to solve with MR)
> > b) These can't be so easily extended. For example, to switch your
> > entire app
On 14 Jun 2006, at 17:19, oggie rob wrote:
> a) The ever-present argument about file extensions & template syntax
> (that we seemed to solve with MR)
> b) These can't be so easily extended. For example, to switch your
> entire app from non-escaping to escaping you have to rename all your
> files
> What do you think of auto escaping being on for .html templates and off for
> .txt templates?
Simon,
Sounds clean but consider:
a) The ever-present argument about file extensions & template syntax
(that we seemed to solve with MR)
b) These can't be so easily extended. For example, to switch yo
Hmm. I see two different cases that get munched in the discussion:
a) You run data through some filter or inside a html tag where it shouldn't be
escaped.
For this, you (or the designer) need to specify this in the template.
b) Parts of the context are pre-assembled html or are already unesc
On 14 Jun 2006, at 15:48, Derek Anderson wrote:
> the idea of it being in the model was more along the lines of
> validating
> incoming data than it was munging outgoing. html is almost always
> either acceptable or it's not in a given field. (per your example:
> who
> want's arbitrary HTM
On 6/14/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> the idea of it being in the model was more along the lines of validating
> incoming data than it was munging outgoing. html is almost always
> either acceptable or it's not in a given field. (per your example: who
> want's arbitrary HTML
the idea of it being in the model was more along the lines of validating
incoming data than it was munging outgoing. html is almost always
either acceptable or it's not in a given field. (per your example: who
want's arbitrary HTML allowed in a plain text email and not in a web
page?)
but i sti
On 14 Jun 2006, at 14:44, Derek Anderson wrote:
> the problem is that there are multiple types of escaping. sql? html?
> javascript? new-web-tech-of-the-day? do you escape them all, or
> just some?
>
> personally, i don't like my framework to auto-munge my data behind my
> back. esp. in wa
the problem is that there are multiple types of escaping. sql? html?
javascript? new-web-tech-of-the-day? do you escape them all, or just some?
personally, i don't like my framework to auto-munge my data behind my
back. esp. in ways that are not clearly defined and could change on a
whim. t
Hi, all. First time caller here.
On 6/14/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> In my opinion, there are three viable solutions:
>
> 1. auto_escape is on for ALL Django templates ALL the time. It may
> well be too late to do this due to backwards compatibility concerns.
>
Another concer
Simon Willison wrote:
>
>
> The ideal situation would be for auto_escape to be on by default, and
> let templates turn it off if they need to. This has serious backwards
> compatibility issues however.
the official opinion is that there's no backward-compatibility
guarantees before 1.0 any
On 14 Jun 2006, at 00:07, Rudolph wrote:
> I like your idea of explicitly turning it on or off globally in the
> settings. In addition to that idea I would suggest an option to set
> the
> behaviour for a whole Template, something like:
>
> tmpl = loader.get_template('example.csv')
> tmpl.auto
Hi,
Some time ago, I wrote something in this direction, it's a Template
subclass that escapes all variable nodes. I found that I don't use
it, but perhaps someone wants to build upon it. It works, but misses
a proper loader.
If you have a pre-formatted string, you have to turn it into an
Hi,
Pro:
- secure by default: you do not miss one variable because you have to
explicitly disable it for a variable, I would prefer a little more
verbose syntax like: {{ variable|noescape }}.
Con:
- explicit escaping is better then implicit escaping (no magic behind
the scenes)
I like your idea
1 - 100 of 101 matches
Mail list logo
