Be Safe with Django 1.2


Transitioning to using Django 1.2 templates with AppEngine has been a real adventure, and this is just the second in a series of posts about my experience with it. I am glad to have the increased power that is in the newest version of the template language, but I have paid a steep price in hours spent making changes to be compatible with it.

For a good chunk of last night and spots of time here-and-there today, I have been going through my code and adding the |safe filter to variables that might contain HTML that needs to be rendered. Django 1.2 assumes that you want your variables to be escaped. While that is a good practice to prevent spammers and script kiddies from abusing your site, I always assume that I need to sanitize on input rather than output, and I consider all of my stored data to be safely renderable.

There are a couple of ways to prevent Django from escaping your variables. I have chosen to append the |safe filter. Why? Well, it is safer. As I said, I sanitize on input, but there’s always a chance that I will have overlooked something, and some persistent fool will figure out a way to game me. As long as I have to manually look at my templates, models and controller code before I decide that something is safe, I feel confident that my application is going to be OK.

If you are less risk averse -- or maybe just lazier -- than I am, you can get the same effect by simply placing an {% autoescape off %} {% endautoescape %} at the outermost level in your template hierarchy. To me, that is tempting fate and failure, but you are the best judge of own your own liabilities.

Most importantly, don’t get caught with a busted app after you innocently follow the directions on how to set a specific version of Django in you AppEngine application. This blog spent several days with a non-functioning Atom feed because I never really thought to check it after the upgrade.

Who really thinks about their feed once it’s working?