Also, I don't have time to read every google group posting anymore. This may
have been suggested in a thread that was buried from those who just scan the
post titles.

Changes like this need to be called out, we need some way of being able to
review and vote for certain changes.... something like uservoice but for
bugfixes.

--
Thadeus




On Fri, Jul 23, 2010 at 5:31 PM, mr.freeze <[email protected]> wrote:

> There was talk of a week long RC period for all releases unless there
> was an important bug fix but we seem to have reverted to old habits.
>
> On Jul 23, 5:28 pm, Thadeus Burgess <[email protected]> wrote:
> > I also agree that this is a break in backwards compatibility. It is also
> a
> > change that was never considered for longer than 15 minutes before the
> > decision to make the change was implemented.
> >
> > I really wish we would put certain things such as this under a review
> board
> > so they don't get into web2py and break things!
> >
> > --
> > Thadeus
> >
> > On Fri, Jul 23, 2010 at 2:33 PM, MikeEllis <[email protected]
> >wrote:
> >
> > > Typo: 2 sentence in prior message should read
> >
> > > " ... after XML() supplies the unescaped string."
> >
> > > On Jul 23, 3:28 pm, Michael Ellis <[email protected]> wrote:
> > > > 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