Implicitness in this case is a desirable attribute, imho. For output filtering it would be nice to have HTML escaping be a sitewide default. This is just good security practice, deny by default, and allow by exception. If I must have a < or a > in a output variable I would be happy to have to explicitly turn it off (although it's not entirely clear how to do this from the wiki page). This also would increase my confidence level that less experienced programmers won't do something silly.
For a good security posture, though, you need input filtering in addition to output filtering. Allowing dangerous _javascript_ into a database and then trying to block it on the way out is not a winning strategy. The danger is that someone writes a new view and forgets to filter it properly.
The best solution to such a hairy problem is defense in depth. Catch it on the way in, and catch it on the way out. This also let's people safely (sorta) use AJAX rich text HTML editors and such.
Cheers,
~ol
On 11/7/06, SmileyChris <[EMAIL PROTECTED]> wrote:
> ... There's been
> extensive discussion of this on the developer list and thus far
> no-one's stepped up with a clean implementation that doesn't get in
> the way of some use cases (keep in mind that Django's template system
> is expected to be able to produce more than just HTML ...
I dunno, I reckon my implementation is pretty clean
(http://code.djangoproject.com/wiki/AutoEscape%20alternative )
When I brought it up on the group a while ago, I hit resounding
silence. It doesn't seem to be the hot topic it was a while back.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
