Are you calling handlebars a "string concatenation engine"?
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@wikimedia.orgwrote:
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@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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l