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" <[email protected]> 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 <[email protected]>
> 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
> > [email protected]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
