I think I just invented this "string concatenation
engine" expression but
...yes. Handlebars uses a lexical parser but once templates are compiled
parameter substitution is done concatenating strings. I was referring to
this second step.
Example Template:
<h1>Handlebars JS Example</h1>
<script id="some-template" type="text/x-handlebars-template">
<table>
<div>
Name {{name}}
</div>
</script>
Template once compiled:
(function() {
var template = Handlebars.template, templates = Handlebars.templates =
Handlebars.templates || {};
templates['template_test.html'] = template({"compiler":[5,">=
2.0.0"],"main":function(depth0,helpers,partials,data) {
var helper, functionType="function",
escapeExpression=this.escapeExpression;
return "<h1>Handlebars JS Example</h1>\n<script
id=\"some-template\"
type=\"text/x-handlebars-template\"> <table>\n <div> \n
Name "
+ escapeExpression(((helper = helpers.name || (depth0 &&
depth0.name)),(typeof
helper === functionType ? helper.call(depth0,
{"name":"name","hash":{},"data":data}) :
helper)))
+ " \n </div>\n</script>\n\n";
},"useData":true});
})();
On Wed, Apr 2, 2014 at 3:28 PM, C. Scott Ananian <cananian(a)wikimedia.org>wrote;wrote:
Are you calling handlebars a "string
concatenation engine"? In the
spacebars implementation (and my/gwicke's prototype) it is a structured DOM
engine. Don't confuse surface syntax with implementation.
--scott
On Apr 2, 2014 7:33 AM, "Nuria Ruiz" <nuria(a)wikimedia.org> wrote:
>The
example might not have been the most helpful one. Consider a
handlebars
>template like this:
><a href="{{url}}">{{title}}</a>
True, much better example to state the point. Now, as I think I
mentioned
earlier there are two cases that need to be
treated differently than
anything else: links and translations/localizations.
In this case I wouldn't want the url (or translation) to be plainly
parsed.
Rather I would do:
<a href="{{urlBuilder p1=param1 p2=param2}}">{{title}}</a>
Where urlBuilder is a user defined function that decides on "lawful"
input
and output scheme.
This would work just the same for translations {{translateGender
maleTranslation femaleTranslation name=param}} where translateGender is
also defined by us.
But these are basically the two only schemes you need to treat
differently, the context in these two cases is very precise and thus much
more manageable.
>For this you need special and ideally
automatic sanitization for href
attributes (and src & style), which is
>>what KnockOff/TAssembly
provides.
Sure, that works just as well. But overall is a
pretty similar solution
to
having a url builder function executed from the
template engine with the
drawback that is less performant. I know you guys are set on the DOM
based
engine but maybe it is worth thinking how to fit
client side translations
on that scheme as translations bring their own escaping problems (if you
have done so please disregard).
My bigger point was to highlite that with a string concatenation engine
you
can satisfy security concerns plus have a
template engine that performs
really well if you respect the data and markup separation.
On Tue, Apr 1, 2014 at 10:23 PM, Gabriel Wicke <gwicke(a)wikimedia.org>
wrote:
On 03/30/2014 02:23 AM, Nuria Ruiz wrote:
> What I am saying is that the parsing and escaping scheme we need is
much
> > simpler if you disallow the use case of passing the template engine
> > something that is not data.
> >
> > Let me explain as this as it has to do more with correctness that
with
security per se:
A template engine objective is to separate data from markup. In your
example you are passing the template 'class="anything"' or
'onclick="something"' neither "class" nor "onclick"
are data.
The example might not have been the most helpful one. Consider a
handlebars
> template like this:
>
> <a href="{{url}}">{{title}}</a>
>
> Even with double-stashes you'll be in trouble if your url data happens
to
be
'javascript:alert(cookie)'. For this you need special and ideally
automatic
sanitization for href attributes (and src &
style), which is what
KnockOff/TAssembly provides.
Gabriel
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l