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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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,
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
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:
>>
>>
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
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
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:
39 matches
Mail list logo
