On 19.03.2014 12:10, Peter Kaminski wrote: MediaWiki Parser itself could be used for skinning as well with some features disabled. But actually just associative nested arrays are good enough as template engine, which are used for example in Drupal: https://drupal.org/node/930760 |// New method of generating the render array and returning that function mymodule_ra_page() { $output = array( 'first_para' => array( '#type' => 'markup', '#markup' => '<p>A paragraph about some stuff...</p>', ), 'second_para' => array( '#items' => array('first item', 'second item', 'third item'), '#theme' => 'item_list', ), ); return $output; }| Each key of such associative array can be mapped to view method, while it's values are view parameters (properties). Quite flexible, fast and powerful approach which also allows to late manipulation of Output. Dmitriy

String based template engines (like handlebars) do escape as a default, you have to use "special" markup for it not to escape. Can you explain in more detail what is the security concern with those? On Wed, Mar 19, 2014 at 7:51 PM, Chris Steipp &lt;csteipp(a)wikimedia.org&gt; wrote:

Right, the engine would render: <div class=1234 onClick=doSomething()> </div> because it only escapes HTML by default. Now, note that the problem can be fixed with <div class={{makeStringSafe something}}> Where "makestringSafe" is a function defined by us and executed there that escapes to our liking. This is equivalent to what we would need to do in PHP server side if we used PHP native templating. We would need to implement an escaping function like "makeStringSafe" that we would execute like: <div class="View::makeStringSafe($this->something)"></div> What I wanted to clarify (regarding Sumana's first e-mail) is that when it comes to security we would need to take the same precautions with a string based javascript engine than we would do with any PHP engine we choose. Namely, as you said, spot the lack of "makestringSafe" via CRs. To be completely fair, the "makeStringSafe" could be inserted with a build/template compilation process and thus we would not need CRs but rather we could rely on automation. On Wed, Mar 26, 2014 at 2:43 PM, Chris Steipp &lt;csteipp(a)wikimedia.org&gt; wrote:

Note that my favorite "handlebars-like" template engine is currently "spacebars", developed as part of the meteor.js project. This does safe structured interpolation, so it's not really a "string-based" template engine any more -- but it still contains the same minimalist markup (it basically looks identical to handlebars, it's just a new implementation). I've worked some with gwicke on spacebars support for his templating project. The other important aspect which I haven't seen mentioned yet is editor support. Where does using the template system fall, on a scale with "writing an article for humans" on one side and "writing executable code" on the other? Even this is not necessarily straightforward to assess. As I understand it, one of the advantages of KnockOff is that, although at a raw HTML level it looks cumbersome for a human to author, it is structured in a way that would make it easier to integrate with something like Visual Editor, with simple properties that can be added to sample text to turn it into a template. I personally lean toward "handlebars"-style engines, because the extremely minimalist syntax makes it easy for non-coders to author directly. A user-friendly editor for such a template language would probably expose separate "content" and "code" views of a template. Basic templates wouldn't have any code, but advanced templates would use something like Scribunto for easy editing of the code associated with a template. --scott -- (http://cscott.net)

Urls in the template engine need to be handled on their own, sure. But what template engine does not work in this fashion? There are three separate "entities" you normally deal with when doing replacement: translations, urls and plain attributes. I see. Sorry but where I disagree is that the "quote me this replacement" is a lawful case for the template engine. The line above is doing a lot more than purely templating and on my opinion it does little to separate data and markup. Which is the very point of having a template engine. But if you consider that one a lawful use case, you are right. The example I provided does not help you. On Wed, Mar 26, 2014 at 6:15 PM, Chris Steipp &lt;csteipp(a)wikimedia.org&gt; wrote:

$anythingElse 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. Thus what I am arguing is that the template engine should not support the use case of "add any random attribute or javascript to my html element with the right set of quotes" as a "lawful" use case. The template engine should not be expected to parse and insert code and "onclick" is code. With a new template engine our main objective should be to separate data from markup, not supporting an style of coding that includes "onClick" attributes mixed with HTML which was prevalent years ago or css classes mixed with controller code. On my experience reducing use cases for template engine to just data handling while having specific functions that deal with links and translations simplifies the escaping problem greatly as you do not need context aware escaping. You can "js-escape" any piece of data sent to the engine cause you know you do not support the use case of sending javascript to be inserted. On Wed, Mar 26, 2014 at 6:41 PM, Chris Steipp &lt;csteipp(a)wikimedia.org&gt; wrote: > On Wed, Mar 26, 2014 at 10:30 AM, Nuria Ruiz &lt;nuria(a)wikimedia.org&gt; wrote: > > > >Additionally, how you escape a plain parameter like class vs. an > > >href vs. a parameter that is inserted into a url vs. an id attribute are > > >all different escaping strategies. > > Urls in the template engine need to be handled on their own, sure. But > what > > template engine does not work in this fashion? There are three separate > > "entities" you normally deal with when doing replacement: translations, > > urls and plain attributes. > > > > > > $anythingElse > > I see. Sorry but where I disagree is that the "quote me this replacement" > > is a lawful case for the template engine. > > > I'm not sure I understand what you're saying here. Do you mean > makesafeString in your example shouldn't quote the text, but should instead > remove space characters? > > > > The line above is doing a lot > > more than purely templating and on my opinion it does little to separate > > data and markup. Which is the very point of having a template engine. > > > > But if you consider that one a lawful use case, you are right. The > example > > I provided does not help you. > > > > > > On Wed, Mar 26, 2014 at 6:15 PM, Chris Steipp &lt;csteipp(a)wikimedia.org&gt; > > wrote: > > > > > On Wed, Mar 26, 2014 at 9:44 AM, Daniel Friesen > > > &lt;daniel(a)nadir-seen-fire.com&gt;wrote;wrote: > > > > > > > On 2014-03-26, 9:32 AM, Nuria Ruiz wrote: > > > > >> The issue is that they apply the same escaping, regardless of the > > > > >> html context. So, in Twig and mustache, <div > > > class={{something}}></div> > > > > is > > > > >> vulnerable, if something is set to "1234 onClick=doSomething()". > > > > > Right, the engine would render: > > > > > > > > > > <div class=1234 onClick=doSomething()> </div> > > > > > > > > > > because it only escapes HTML by default. > > > > > Now, note that the problem can be fixed with <div > > > class={{makeStringSafe > > > > > something}}> > > > > > > > > > > Where "makestringSafe" is a function defined by us and executed > there > > > > that > > > > > escapes to our liking. > > > > How does a custom function jammed into the middle of a Mustache > > template > > > > fix the issue when the issue is not that foo={{something}} doesn't > > > > escape, but is that quoting is needed instead of escaping, and > Mustache > > > > isn't context sensitive so neither Mustache or a custom function know > > > > that foo={{something}} is an attribute value in need of quoting? > > > > > > > > > > Exactly. Additionally, how you escape a plain parameter like class vs. > an > > > href vs. a parameter that is inserted into a url vs. an id attribute > are > > > all different escaping strategies. So there would be many different > > > "makeXXXXStringSafe" and probably "quoteAndMakeXXXXStringSafe" > functions, > > > and code review would have to make sure the right one was being used in > > the > > > right place. Which means someone who is familiar with all of the xss > > > techniques would need to code review almost all the templates. > > > > > > For comparison, using our current html templating (as much as it > sucks): > > > > > > $html = Html::element( 'div', array( 'class' => $anything ), > > $anythingElse > > > ); > > > > > > The developer doesn't need to have any knowledge of what escaping needs > > to > > > apply to the class attribute vs the text. > > > > > > > > > > > > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [ > http://danielfriesen.name/ > > ] > > > > > > > > > > > > > > > _______________________________________________ > > > 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 >

On 03/30/2014 02:23 AM, Nuria Ruiz wrote: 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

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" &lt;nuria(a)wikimedia.org&gt; wrote:

On 04/02/2014 04:33 AM, Nuria Ruiz wrote: The runtime is string-based for performance in both cases. That's what makes TAssembly so fast [2]. The difference is that the DOM-based KnockOff compiler systematically enforces DOM balancing and attribute sanitization, while without such a compiler you have to do so manually. Gabriel [1]: https://www.mediawiki.org/wiki/Talk:Requests_for_comment/HTML_templating_li… [2]: https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library…

On 03/26/2014 10:55 AM, Chris Steipp wrote: When compiling from DOM to the TAssembly JSON IR we encode the attribute context in the 'attr' binding. While executing this binding TAssembly automatically escapes href / src and style attributes using the same sanitization logic as used in Parsoid, which in turn is a direct port of MediaWiki's Sanitizer.php. Despite offering this level of security support it is the fastest library in our benchmarks. KnockOff is compiling to TAssembly from KnockoutJS syntax, but other front-end syntaxes are possible like cscott's Spacebars to TAssembly compiler. We chose the KnockoutJS syntax primarily for its ease of implementation (the expression grammar is 70 lines, and DOM parsing is readily available). It also supports powerful and general parameter passing which is useful for things like i18n, and has good potential support for server-side pre-expansion followed by client-side updates by virtue of its attribute syntax. Last night Matt has been back working on the PHP port of TAssembly. We'll probably have an update on this in the next days. Gabriel

On 2014-03-26, 10:15 AM, Nuria Ruiz wrote: And Chris explained that if 'something' was 'some-text onclick=doSomething()' instead of 'some-text' then instead of: <div class=some-escaped-text> </div> The template engine would output: <div class=some-escaped-text onclick=doSomething()> </div> Creating an XSS vector. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

On 03/19/2014 09:52 PM, Gabriel Wicke wrote: Gabriel, Matt - is the PHP runtime ready? Want to talk about it in this week's RfC meeting? -- Sumana Harihareswara Senior Technical Writer Wikimedia Foundation

On Tue, Apr 1, 2014 at 1:33 PM, Gabriel Wicke &lt;gwicke(a)wikimedia.org&gt; wrote: I'm eager to get some closure on the overall RFC about HTML templating myself. Am I right to assume that the process is: 1. Get Knockoff complete enough that we can fairly evaluate it against the other proposals 2. Reopen the conversation about various alternatives 3. Pick something Correct? Rob

The mobile web team will be evaluating Gabriel's KnockoutJS template implementation sometime between April 14 and April 28. The things we will be looking at include: how well it will work for mobile's current templating needs, how appropriate it is for mobile delivery, and how much effort would be involved in migrating our existing templates to it. We'll update the list with our findings then. Ryan Kaldari On Tue, Apr 1, 2014 at 4:10 PM, Gabriel Wicke &lt;gwicke(a)wikimedia.org&gt; wrote:

TL;DR: who's testing out the non-Knockout approaches? Much thanks to everyone who corrected & enlightened me! I was especially grateful to Chris Steipp's explanation: and Peter Kaminski's reminder of the "separation of concerns" concept, and C. Scott's explanation of how we could balance usability for human editors against easy integration with VE and executability http://www.gossamer-threads.com/lists/wiki/wikitech/445152#445152 . Thanks also to Nuria Ruiz and others for the corrections on security stuff! Now that we know the mobile team is checking out the KnockoutJS idea in late April and reporting back to the list in late April/early May, I'm wondering about something C. Scott said: On 04/01/2014 07:11 PM, C. Scott Ananian wrote: That makes sense. So who is testing out/reporting about the other approaches or implementations? To repeat my question from March 18th: oojs - https://www.mediawiki.org/wiki/OOjs_UI -- could use this toolkit with one of the other template approaches, or maybe this is enough by itself! Currently used inside VisualEditor and I am not sure whether any other MediaWiki extensions or teams are using it? Should we try using this in another team? -- Sumana Harihareswara Senior Technical Writer Wikimedia Foundation

On Wed, Apr 2, 2014 at 2:09 PM, Sumana Harihareswara &lt;sumanah(a)wikimedia.org&gt; wrote: I have a design in my head that separates code and presentation in a user-facing template system and is based on the Scribunto codebase. The idea would be to combine handlebar's very simple user-facing syntax with Scribunto's code editor for the non-presentational aspects. Every template would have a (possibly-empty) piece of code associated with it. Code is edited with a code editor, the presentation is edited with visual editor. That said, this is strictly a weekend/airplane trip project for me at the moment, and I keep getting distracted by hacking on Scribunto/JS and v8js and node, all of which are (strictly speaking) not necessary for the basic idea, but are fun to hack on. The last time I spent a chunk of time on this, I added basic handlebars support to gwicke's TAssembly prototype, which really is very very fast. --scott -- (http://cscott.net)

On Wed, Apr 2, 2014 at 11:09 AM, Sumana Harihareswara &lt;sumanah(a)wikimedia.org Besides those listed at [1] The Flow discussion system needs to render templates on both the client and server[2]. The Flow team is going to use handlebars.js and its lightncandy PHP implementation; we wanted to try KnockOff/TAssembly but the timing isn't right. We will be ripping off :) MobileFrontend's integration of Hogan.js client-side templates. (Gabriel Wicke wrote "I know that for example handlebars is used in a few teams right now." -- who else?) As I understand it, OOjs UI is more a rich widget library rather than a templating system. You would compose a page out of widgets that render what you want, and yes you could use OOjs UI with a templating engine (it operates on jQuery elements). The Multimedia team is using OOjs UI for the "About this file" dialog in the Media Viewer[3] (currently a beta feature). They haven't styled it to use Agora controls. Mobile is using VisualEditor with the beginnings of an Agora theme. Hope this helps, corrections welcome. [1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library… [2] https://www.mediawiki.org/wiki/Flow/Epic_Front-End#Templating [3] https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer -- =S Page Features engineer on the Flow team

On Tue, May 13, 2014 at 1:42 PM, Sumana Harihareswara &lt;sumanah(a)wikimedia.org Unfortunately, that card got moved to the backlog due to time constraints and higher priorities, so we have not yet evaluated the KnockoutJS template implementation. We are continuing to use hogan/handlebars in the meantime. Ryan Kaldari