chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] More thoughts on Ersatz


From: Peter Bex
Subject: Re: [Chicken-users] More thoughts on Ersatz
Date: Thu, 14 Mar 2013 00:20:26 +0100
User-agent: Mutt/1.4.2.3i

On Wed, Mar 13, 2013 at 05:13:10PM -0600, Matt Gushee wrote:
> On Tue, Mar 12, 2013 at 1:11 PM, Peter Bex <address@hidden> wrote:
> > Not to sound like a broken record, but I'd add that this applies 100% to
> > HTML/XML as well.  I would suggest using SXML or something similar over
> > a string-based templating language.  This allows you to prevent
> > injection bugs as well as accidental mismatching of opening/closing tags.
> 
> Many designers are familiar with [X]HTML of course,
> but I've seen too many people go into fight-or-flight mode as soon as they
> start seeing unfamiliar tag names to feel optimistic about any kind of
> non-HTML markup.

I haven't seen that in practice yet, but I suppose that might be a problem.

> Also, backing up a step to your SXML recommendation, I actually don't see
> what SXML per se has to do with preventing injection bugs. After all, it is
> just a representation of a data tree, and if it is used template-wise,
> *something* has to be interpolated.

It strictly separates strings from lists.  I wrote up a blog post about
this issue (hence the "broken record" bit), see
http://www.more-magic.net/posts/structurally-fixing-injection-bugs.html

> Now, I have seen that at least some of
> the SXML tools for Chicken have built-in escaping for markup characters (as
> does Ersatz, by the way)

How does that work when injecting pre-rendered HTML into your HTML?

> but what about malicious Javascript? But maybe I'm
> missing something pretty obvious ... I do have to admit I don't know as
> much as I should about the whole malicious-code injection issue.

That's not handled automatically by SXML.  However, it's not considered
very "clean" to use inline Javascript, just like it isn't clean to use
inline CSS.  Of course occasionally you might do so, but generally it's
much more maintainable to put Javascript into its own file and have it
fire on documentready.

> Finally, an idea has occurred to me. What about a templating system where
> what actually gets used at runtime is SXML, but designers could create
> templates in XHTML, then when they are satisfied with the design, use a
> preprocessing tool to convert them to SXML? That would at least ensure
> well-formed markup.

Yep, that would be good.  Representation and surface syntax don't
neccessarily need to be equivalent, though the Lisper in me disagrees
about that being a good idea :)

Cheers,
Peter
-- 
http://www.more-magic.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]