Kris, Did you get a chance to look at this ?
Anything missing or anything I can do to help integrating this in sf 1.x ? cheers, Victor On Aug 9, 3:10 pm, Victor Berchet <[email protected]> wrote: > I have updated the patch to fix getRaw() altogether which was > suffering from the same issue & added the unit tests -> ready to be > integrated in sf1.x. > > see:http://trac.symfony-project.org/attachment/ticket/8861/escape.2.diff > > Cheers, > Victor > > On Jul 26, 6:31 pm, Kris Wallsmith <kris.wallsm...@symfony- > > project.com> wrote: > > I'll take a look. The concrete "get" method should probably just be removed > > in Symfony2. > > Kris > > > -- > > > Kris Wallsmith | Release Manager > > [email protected] > > Portland, Oregon USA > > >http://twitter.com/kriswallsmith > > > On Jul 26, 2010, at 4:59 AM, Victor Berchet wrote: > > > > When output escaping is turned on in symfony 1.4 (also seems to be the > > > case in symfony2), calling the get method on an object would result in > > > calling the get method of sfOutputEscaperObjectDecorator which only > > > accepts a single argument (without taking the escaping method into > > > account). > > > > Then trying to call a get method with more than one parameter would > > > not produce the expected result. A very good example is trying to call > > > $sf_params->get(<my name>, <my default value>). "my default value" > > > would be considered as the escaping method and would never be > > > propagated to the original object. > > > > This is very annoying plus the behavior is non consistent with the > > > behavior when escaping is turned off (then the second parameter would > > > be taken into account). > > > > This has been detected long ago (http://trac.symfony-project.org/ > > > ticket/1775) but never fixed. I propose a > > > fix:http://trac.symfony-project.org/ticket/8861. > > > > The classic work around (as described in issue 1775) is to use > > > $sf_data->getRaw('sf_params')->getget(<my name>, <my default value>). > > > However this returns an un-escaped value and then might expose a > > > security breach. > > > > I believe that the proposed fix is not an API change hence can be > > > applied safely to symfony 1.4. It seems to me that symfony2 is also > > > affected (by reading the code) and should be fixed in the same way. > > > > Cheers, > > > Victor > > > > -- > > > If you want to report a vulnerability issue on symfony, please send it to > > > security at symfony-project.com > > > > You received this message because you are subscribed to the Google > > > Groups "symfony 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/symfony-devs?hl=en -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony 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/symfony-devs?hl=en
