On 8/1/07, Deryck Hodge <[EMAIL PROTECTED]> wrote: > May I ask a clarifying question here? Is autoescaping going to be on > by default, or no? And what exactly is it that's being added here -- > a template tag for turning on/off autoescaping?
Yes, the plan is to have autoescaping on unless you explicitally turn it off in your template (or by not using ".html" template file names if Tom's proposal holds). What's being added is both the autoescaping behavior -- Django currently does no automatic escaping whatsoever -- and the mechanism to turn it off. I think the current debate has moved away from "should we have autoescaping" since I think we're all pretty much agreed that *some* form of automatic escaping is neccisary if we're gonna protect our users from shooting themselves in the foot. > I know we've gone round and round about this, so I don't mean to cover > old ground, but I did search the archives and wiki a bit and I'm still > not clear. If it's not on by default, as James said, how does this > make life safer for anyone? Don't get me wrong, I've argued against > autoescaping before, but if it's in the framework why not turn it on > by default? Yup, you said it. If we're gonna do this, we should do it right. I've been pretty much convinced that we've got to have autoescape, and it's got to be on by default. It's basically a tradeoff between annoyance (of having to turn it off when you need it off) and security, and security has to win that argument. > And I guess I don't really see the difference in turning > on/off autoescaping globally in a base template vs. a global setting. The problem with a global AUTOESCAPE setting is that it makes writing distributable Django applications impossible. OK, that came out a bit cryptic, so let me explain: Back in my days as a PHP developer, I tried to write a handful of distributable libraries (including a really, really shitty ORM. You think Django's ORM is weak? You shoulda seen this one...). It isn't long until I ran into trouble with magic_quotes. I'll save the heartache, but the short version is that it's actually impossible to write code that handles magic_quotes defensively. You literally *can't* write code that works for any input without dictating that magic_quotes must be on or off. >From a user's point of view, it sucks even harder. So you install that cool PHP forum everyone's been crowing about. In the process, you turn off magic_quotes like the docs tell you too. A few months later, you install new blog software, and start getting weird SQL errors. Oops, that blog needs magic_quotes on, but if you do that, the forum breaks... The lesson here is that code interpretation *can't* be dependent on environment. If we have a global autoescape setting, we can kiss easily-distributable Django apps goodbye. If, however, we turn it off in a base template, we're golden; apps can simply distribute a base.html that does whatever's right for the library. Jacob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
