[Owncloud] Problems with the current template engine

[Victor Dubiniuk]

Hi Bernhard,

I have a long experience with Smarty and tried a couple of other template
engines. Most of them is nothing but PHP written in PHP.
There are some brilliant exclusions like Slim and Haml in Ruby but both are
not implemented in PHP completely.
I consider phtml to be the best option for templates.  One can say it is
weird for designers but any other non-HTML syntax is weird for designers
either.
It's just my humble opinion.  :)

---
Victor

On Tue, Oct 9, 2012 at 5:06 PM, Bernhard Posselt <nukeawhale at gmail.com>wrote:

> Hi guys,
>
> I've ran into multiple problems with the current template engine setup.
>
> * Lack of documenation:
> Since these are only used by Owncloud, we have to maintain the
> documentation on the template engine. Using a third party engine would
> simplify documentation since we only would have to document how this is
> built into Owncloud. Not to mention that there isnt actually any
> documentation about the current templating engine at all from what Ive
> found (http://api.owncloud.org/classes/OCP.Template.html)
>
> * Lack of template inheritance:
> Currently we can only organize templates by splitting them into
> different parts and including them in a Top-Down like fashion. Template
> inheritance solves this kinds of problems (an example:
>
> https://docs.djangoproject.com/en/dev/topics/templates/#template-inheritance
> )
>
> * Weird and unsafe XSS escaping:
> Most important topic for me. We currently escape values when they're
> assigned to a template like $tpl->assign('var', $var). If you dont want
> to invoke the XSS protection on the variable, you use
> $tpl->assign('var', $var, false) which is really weird and non obvious.
> Also: What do we escape? IIRC variables and arrays, but what about
> objects? We at the news app pass an array with objects to the template
> layer. Are the properties escaped? If they are, this could lead to
> potential weird behaviour, not to speak of the performance impact
> (reflection). As you see, theres no sane way to do XSS escaping when
> passing values to the template layer.
>
> The solution? Easy: escape the values when they are printed to the
> template. Most template engines forbid you to use PHP in the templates
> (which is a good decision) and provide their own print statements like
> Django's {{ variable }} or Rail's <%= variable %>. All printed values
> are automatically escaped by default! If you want to prevent escaping
> you just use a filter like {{ var|safe }}. The word safe alone gets me
> thinking: why is it called safe? What are the risks?
>
> * Allowing PHP code in templates:
> This is not only a security problem stated by the previous point, but
> also an invitation to code mess. Allowing PHP code in the template
> tempts people to disregard the MVC principles (like for instance doing
> database queries in the templates, we have that problem too, I admit),
> which makes your templates really inflexible and really hard to change.
> Everytime I try to clean up our templates or adjust them, I give up in
> frustration because I'd have to adjust all templates, some of which are
> generated in a recursive way and thus also very complicated to understand.
>
> Coming from Django I've looked at two similar engines:
>
> http://www.h2o-template.org/
> http://twig.sensiolabs.org/
>
> Both have good documentation, Twig doesnt do autoescaping but theres a
> block for that. I'm curious about other suggestions, and it would also
> be fine if they could be reviewed from a security context.
>
> PS: Sorry for the long post, here's a potato
> http://efr0702.files.wordpress.com/2012/03/potato-b.jpg
>
> Cheers
>
> Bernhard Posselt
>
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20121009/c94a779e/attachment.html>