I liked the original proposal (mine!) to extend addslashes rather than to nearly-duplicate its functionality in another filter, but I can see the logic of slicing these things finely. I like that the docs for addslashes refers to escapejs. For the purposes of education, the escapejs docs should explain why they convert </ into <\/: a small mention there could go a long way to ensuring that future developers understand the problems at hand.
--Ned. Andrew Durdin wrote: > On 10/17/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > >> However, there are many strings that can be passed through that >> filter and sill will break javascript string literals. >> > > Specifically, as you point out, strings that contain "</script>" -- > the main point here is to reduce the chances of XSS attacks when > embedding user-originated data into scripts. > > >> 4131 now has a patch (from Andy Durdin) which would introduce a new >> defaultfilter named escapejs. It does the complete job of escaping >> anything that could break out of a string literal. >> > > Credit where it's due; The meat of the patch is Jeremy's, I just > tidied it up a tad. > > Andrew > > > > > -- Ned Batchelder, http://nedbatchelder.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
