Urgh!  FWIW, putting XML() around the strings doesn't seem to work.  Looks
like the escaping is applied after XML() supplies the unquoted string.

I tried
{{
for optstring in (schartoptions, countpieoptions, cchartoptions):
    optstring = XML(optstring)
    debug("opstring=%s"%optstring)
    pass
}}
after assigning the strings and before they are used in inside the <script>
tags.

The debug() calls show the strings with the single quotes unescaped, but
they still end up being escaped in what gets sent to browser.






On Fri, Jul 23, 2010 at 2:16 PM, Michael Ellis <[email protected]>wrote:

> 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">
>> >     /* <![CDATA[ */
>> >     $("#{{=ks+kc}}").sparkline(data.wsc.{{=ks}}.{{=kc}},
>> {{=schartoptions}}
>> > </script>
>> >
>> > With an earlier web2py, it produces the desired result,
>> >
>> > $("#solution0").sparkline(data.s.solution0, {
>> >     type: 'bar',
>> >     barColor: 'green',
>> >     chartRangeMin: '0',
>> >     chartRangeMax: '1'
>> >     }
>> >     );
>> >
>> > but now (at tip) I get
>> >
>> > $("#solution0").sparkline(data.s.solution0, {
>> >     type: &#x27;bar&#x27;,
>> >     barColor: &#x27;green&#x27;,
>> >     chartRangeMin: &#x27;0&#x27;,
>> >     chartRangeMax: &#x27;1&#x27;
>> >     }
>> > );
>> >
>> > Was this change intentional?  If so, what's the recommended workaround?
>> >
>> > Thanks,
>> > Mike
>>
>
>

Reply via email to