Thanks, Nathan. That's certainly a possibility. It's just that I'm not sure what security issue this change actually fixes. There are no user-supplied strings in what I'm using to generate the jQuery calls. If that were the case, then yes it would definitely be my responsibility to properly sanitize it.
Have to say this feels like a loss of backward compatibility to me. I've got a fair amount of code in this app that uses that technique; it's already inherently messy because of the indirection involved in code generation. Wrapping it all in XML calls just adds to the mess. Hope there's a way to refine the security fix so that it's confined to the areas that matter. Cheers, Mike On Fri, Jul 23, 2010 at 1:56 PM, mr.freeze <[email protected]> wrote: > It was probably introduced as a security fix. You can do: > {{ > schartoptions = XML("""{ > type: 'bar', > barColor: 'green', > chartRangeMin: '%d', > chartRangeMax: '%d' > } > """%(chartmin,chartmax)) > }} > > and it won't be escaped. > > > On Jul 23, 12:39 pm, Michael Ellis <[email protected]> wrote: > > I've got an app with views that generate jQuery code on the fly. This > was > > all working fine until recently, i.e. sometime after 1.92. With more > recent > > builds, single and double quotes in strings are now escaped and it breaks > > the javascript. Here's an example > > > > The view has (with much snipped out): > > > > {{ > > schartoptions = """{ > > type: 'bar', > > barColor: 'green', > > chartRangeMin: '%d', > > chartRangeMax: '%d' > > } > > """%(chartmin,chartmax) > > > > }} > > > > and later on I use the variables within a script tag, e.g. > > > > <script type="text/javascript"> > > /* <
