Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!
I have considered looking at JS MVC setups, but have held off, partly
because it's such a big break from what my team and I are used to, but also
because I've seen others (notably Twitter) return to a more traditional,
server-side html rendering approach after having gone the JS application
route because the performance was so much better. That was 2 years ago
though, so I don't know how much has changed since then.
I've heard good things about AngularJS, so I might look at that for future
projects. In the mean time, I'll look at using __ for templates.
Cheers,
David
Sent from my iPhone
On 27/05/2014, at 9:11 PM, Stefano Torresi wrote:
Personally I'd suggest going for the double underscore notation.
By the way, having been there, this is one of the symptoms that eventually
drove me in the direction of dropping PHP from rendering as much as
possible, especially forms.
Even for apparently simple UIs, integrating server side and client side
HTML processing can become unpractical, to say the least.
Probably it's too late now for your current project, but it's the trend of
the moment anyway, so maybe embrace it for your next one. ;)
Il 25/mag/2014 12:27 "David Muir" ha scritto:
> Jeremiah,
>
> I don’t think mustache would help in this case.
> If we were using mustache, it would expect the template to look like this:
>
>
> but the template we get from Zend\Form would look like this:
> name=“additional[{{rowId}}]” />
>
> The consensus on stackoverflow seem to be to use the textarea hack to
> decode it. Is that safe to do from an xss standpoint?
>
> Cheers,
> David
>
>
> On 25 May 2014, at 6:00 pm, Jeremiah Small wrote:
>
> > Maybe give mustache a try, instead of rolling your own.
> >
> > Jeremiah
> >
> >> On May 24, 2014, at 10:31 PM, David Muir 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.
> >>
> >> >> $field = clone $form->get(‘name’);
> >> $field->setAttribute(‘name’, “additional[{rowId}]”);
> >> echo $form->formText($field);
> >> ?>
> >>
> >>
> >> 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 = $('').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
Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!
Jeremiah,
I don’t think mustache would help in this case.
If we were using mustache, it would expect the template to look like this:
but the template we get from Zend\Form would look like this:
The consensus on stackoverflow seem to be to use the textarea hack to decode
it. Is that safe to do from an xss standpoint?
Cheers,
David
On 25 May 2014, at 6:00 pm, Jeremiah Small wrote:
> Maybe give mustache a try, instead of rolling your own.
>
> Jeremiah
>
>> On May 24, 2014, at 10:31 PM, David Muir 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.
>>
>> > $field = clone $form->get(‘name’);
>> $field->setAttribute(‘name’, “additional[{rowId}]”);
>> echo $form->formText($field);
>> ?>
>>
>>
>> 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 = $('').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
Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!
Maybe give mustache a try, instead of rolling your own.
Jeremiah
> On May 24, 2014, at 10:31 PM, David Muir 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.
>
> $field = clone $form->get(‘name’);
> $field->setAttribute(‘name’, “additional[{rowId}]”);
> echo $form->formText($field);
> ?>
>
>
> 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 = $('').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
Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!
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.
get(‘name’);
$field->setAttribute(‘name’, “additional[{rowId}]”);
echo $form->formText($field);
?>
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 = $('').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
Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!
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 rally 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 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 > 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 > > > > > > >
Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!
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 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 > > >
[fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!
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
