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 statements. While surely auto-escaping could help a lot in escaping XSS, it's not for sure that auto-escaping might complicate things too much. I'd rather like to see how it looks in reality before I could make my own mind up. Just one thing I'd like to comment: >>> One thing that bothered me about the proposal was having the >>> auto-escape property set in the context; which I believe is the wrong >>> place; it should be set in the Template instance (or subclass). A >>> context should be reusable between different templates (e.g. an html >>> page, a JSON object, an XML page). >> As long as you don't put any escaped_strings into the context, the context >> can be used anywhere. >> But as soon as you put any html-escaped stuff into it, you (as programmer) >> have restricted >> the usage of the context. Thus, I don't see a problem here. >> >> Do you agree, or do you see anything I don't? > > No, it's only an issue with unescaped strings. Say I've got a view > which produces either json output (for an API interface) or html output > (for a browser interface) -- I want to use the same context for both, > because they're displaying the same data (perhaps even some html code > which gets used for innerHMTL() by the API); but I don't want the json > one to do the automatic html escaping, or my json strings will be > messed up. Yes, and this must be avoided. See item (a) below. > I'm trying to illustrate with this that the auto_escape flag doesn't > logically belong as a property of the context, but instead as a > property of the template instance or template subclass, or the > renderer's state. Either that or I'm completely misunderstanding the > intended uses of the Context class. There are three aspects of auto-escaping: (a) The kind of auto-escaping depends on the usage of the template and needs to be an attribute of the template (or coded in the Template subclass). (b) Whether or not a string needs to be escaped if it is not already, depends on the surrounding in the template. Thus, we need a method to switch it off by template tags or programmatically within a template filter or tag. (c) Whether or not a string is already in escaped form needs to be marked by the programmer in the view, manipulator or elsewhere. Michael --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
