Maybe give mustache a try, instead of rolling your own.
Jeremiah
> On May 24, 2014, at 10:31 PM, David Muir <davidkm...@gmail.com> wrote:
>
> Hey Marco,
>
> No, the placeholders are not part of user input. They’re hard-coded in, but
> because they’re inside attributes, they’re now getting escaped, when before
> they weren’t.
>
> Eg.
> <script id=“my-template” type=“text/html”>
> <?php
> $field = clone $form->get(‘name’);
> $field->setAttribute(‘name’, “additional[{rowId}]”);
> echo $form->formText($field);
> ?>
> </script>
>
> Then in js, we have something like this:
>
> var template = $(‘#my-template’).html();
> template.replace(‘{rowId}’, valueToInject);
> $(‘#target-form’).append(template);
>
> We’ve gotten around it by using the following trick, but it feels kludgey,
> and doesn’t always work:
> var template = $('<textarea/>').html($(‘#my-template').html()).html();
>
>
> Alternatives that I haven’t tried yet, so I don’t know if all of them will
> work:
>
> 1. hard-code the templates entirely, and forgo using Zend\Form (ugh)
> 2. call html_entity_decode() on the output of formText() before echoing
> (should solve the reliability issues we’ve had with the textarea trick)
> 3. replace the placeholders to use underscores instead of curly braces
> (assuming this would work since that’s what the docs for Form Collections
> uses)
> 4. place the template into a data attribute instead of a <script> element so
> that the browser parses the entities back into regular characters for me
>
> Cheers,
> David
>
>
>> On 24 May 2014, at 9:08 am, Marco Pivetta <ocram...@gmail.com> wrote:
>>
>> Hey David,
>>
>> Template parameter placeholders shouldn't really be part of the user input,
>> should they? I think you had a quite bad security issue upfront there ;-)
>>
>> If you really need unescaped strings, then you could eventually override the
>> `escapeHtmlAttr` helper, but be reeeeeeeeeeeeally careful about what you are
>> doing. I won't take responsibility for any security issues introduced by
>> doing that.
>>
>> Marco Pivetta
>>
>> http://twitter.com/Ocramius
>>
>> http://ocramius.github.com/
>>
>>
>> On 22 May 2014 07:15, David Muir <davidkm...@gmail.com> wrote:
>> The security fix broke our javascript templates that contained form
>> elements. :-(
>> All the curly braces in attributes are being converted to html entities, so
>> our string replace calls aren't finding the braces anymore. Is there a way
>> to easily get the old behaviour?
>>
>> Cheers,
>> David
>>
>>
>>
>>
>> On Wed, Apr 16, 2014 at 6:16 AM, Matthew Weier O'Phinney
>> <matt...@zend.com>wrote:
>>
>>> We've just pushed out several new releases:
>>>
>>> - Zend Framework 1.12.6: This fixes a BC break with regards to a
>>> number of Locales that was introduced in 1.12.4; you can read about it
>>> at http://bit.ly/zf-1-12-6
>>>
>>> - Zend Framework 2.2.7 and Zend Framework 2.3.1: These fix a security
>>> issue reported at
>>> http://framework.zend.com/security/advisory/ZF2014-03 - a potential
>>> XSS vulnerability in a number of ZF2 view helpers. Additionally, ZF
>>> 2.3.1 contains more than 80 bugfixes; you can read about these
>>> releases at http://bit.ly/zf-2-3-1
>>>
>>> If you are using ZF2, and specifically view helpers, we highly
>>> recommend upgrading to either 2.2.7 or 2.3.1 ASAP.
>>>
>>> Packages are available via composer, pyrus, or
>>> http://framework.zend.com/downloads/latest
>>>
>>> --
>>> Matthew Weier O'Phinney
>>> Project Lead | matt...@zend.com
>>> Zend Framework | http://framework.zend.com/
>>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>>
>>> --
>>> List: fw-general@lists.zend.com
>>> Info: http://framework.zend.com/archives
>>> Unsubscribe: fw-general-unsubscr...@lists.zend.com
>
--
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com
