Hi Bernhard, in order to get your problem sorted out you maybe can try following: - replace all calls of echo within the template files by a cal to e.g. p - within the template class we define the function p which actually takes care about html escaping and echos the result. - and for now you simply call assign with false.
Just 2 cents as usual, Tom Am Dienstag, dem 09.10.2012 um 16:55 schrieb Bernhard Posselt: > Hi Frank, > > The issue came up when me and Allessandro were trying to fix a bug and > figure out why stuff was escaped weirdly which causes special characters > to not render properly. Apart from this I think it is important for > enterprise customers, since this would help greatly in making the > software more secure. I don't want to press this too much though since > the 4.5 release is around the corner I just think that this will become > an important topic when we try to improve the code quality and security. > > Bernhard Posselt > > On 10/09/2012 04:42 PM, Frank Karlitschek wrote: > > Guys, > > > > > > templating is our smallest problem at the moment. > > Out current templating is not fancy but works fine. I´m against replacing > > it with something that generates a huge amount of new work and introduced > > new bugs and performance problems instead of working on topics that are > > important for our users like bugs and feature requests on bugs.owncloud.com > > > > > > Frank > > > > > > On 09.10.2012, at 16:26, Bernhard Posselt <[email protected]> wrote: > > > >> Hi Viktor, > >> > >> Yeah, HAML is great :) > >> > >> Could you provide a link to your templating engine, I dont find any > >> information on that on Google. Or do you mean PHP in general (phtml as > >> in the extension)? > >> > >> > >> On 10/09/2012 04:20 PM, Victor Dubiniuk wrote: > >>> 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 > >>> <[email protected]>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 > >>>> [email protected] > >>>> https://mail.kde.org/mailman/listinfo/owncloud > >>>> > >> _______________________________________________ > >> Owncloud mailing list > >> [email protected] > >> https://mail.kde.org/mailman/listinfo/owncloud > > > > _______________________________________________ > Owncloud mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/owncloud _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
