Encoding by default

[Kevin Dente]

First, let me say that Spark looks very cool. Very nice work.

There's been a bunch of discussion in the blogosphere lately about XSS
and encoding output, with the the general consensus being "always HTML
encode your output". Yet no view engines seem to do this. Have you
considered making Spark encode output by default (with a way to
escape, of course)? Or at least giving an expression syntax that
encodes by default (e.g #{expr}, ^{expr}, or whatever).

I know about ${H(expr)}, but that still requires that I remember to
include the call to H. I want the brain-dead, always-do-it, I-don't-
have-to-think-about-it option. I'm more than willing to submit a patch
if that would be helpful.

[Louis DeJardin]

You're right it'd be impossible to add that directly to ${expr} without making it impossible to send ${Html.ActionLink(...)}. I'd hesitate to change the default behavior of ${expr} because it would be a breaking change. We already had ?{cond} added when there was a compelling reason, so I could see this if there was a consensus.

The #{expr} could collide with #statement if it was on the start of a line, so I don't think that'll fly.

<p>^{product.Name}</p>
<p>_{product.Name}</p>
<p>={product.Name}</p>
<p>+{product.Name}</p>
<p>-{product.Name}</p>
<p>{{product.Name}}</p>
<p>!{product.Name}</p>
<p>${product.Name}</p>
<p>&{product.Name}</p>
<p>%{product.Name}</p>
<p>@{product.Name}</p>
<p>~{product.Name}</p>
<p>*{product.Name}</p>
<p>`{product.Name}</p>

Ah, I think & is out... Collides with &entity;...

If anything I think I'd lean towards <p>Product +{product.Name}</p>... It looks a little bit like you meant to add/append the value to the literal html, so implicit encoding would make sense, but even more importantly the [shift] "+{" sequence looks to be keyboard friendly.

[Kevin Dente]

Hmm, I'm kind of partial to ^{product.Name} myself, for some reason.
But I'm cool either way. You're right that +{} is flows pretty well on
the keyboard.

[Chad Lee]

What's wrong with the current way?

${H(myVar)}

I don't see much value in adding a shortcut to this already short method call.

[Torkel Ödegaard]

I kind of liked @{ }, but +{ } is also good.

[Louis DeJardin]

Nothing wrong with ${H(expr)} at all, and I wouldn't suggest the way
that works would change at all. It is an interesting point though that
if you should html encode anything that doesn't explicitly contain
html, it does mean you have to opt-in to that behavior every time you
surface a value.

Saves three whole keystrokes per field too. :)

Say! Along those lines (where a lot of this is personal preference)
what if it was configurable where different prefixes could have
defined wrapping code?

@ or ^ for H(...) would be one example, but another useful one could
be mapping some character like * to Html.ActionLink(...). So you could
use syntax *{"click here", "index", "products"} as a shortcut to all
of the overloads of that particular helper? Never have to type
Html.ActionLink again.

[Kevin Dente]

Interesting idea. How would you envision the configurable prefixes
being defined? In a config file? One concern would be portabillity of
Spark pages across applications, if they each use their own prefix
conventions.

On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> Nothing wrong with ${H(expr)} at all, and I wouldn't suggest the way
> that works would change at all. It is an interesting point though that
> if you should html encode anything that doesn't explicitly contain
> html, it does mean you have to opt-in to that behavior every time you
> surface a value.
>
> Saves three whole keystrokes per field too. :)
>
> Say! Along those lines (where a lot of this is personal preference)
> what if it was configurable where different prefixes could have
> defined wrapping code?
>
> @ or ^ for H(...) would be one example, but another useful one could
> be mapping some character like * to Html.ActionLink(...). So you could
> use syntax *{"click here", "index", "products"} as a shortcut to all
> of the overloads of that particular helper? Never have to type
> Html.ActionLink again.
>

> On 12/17/08, Torkel Ödegaard <torkel.odega...@gmail.com> wrote:
>
>
>
> > I kind of liked @{ }, but +{ } is also good.
>

> > On Wed, Dec 17, 2008 at 5:24 AM, Chad Lee <chadl...@gmail.com> wrote:
> >> What's wrong with the current way?
>
> >> ${H(myVar)}
>
> >> I don't see much value in adding a shortcut to this already short method
> >> call.
>

> >> On Tue, Dec 16, 2008 at 10:21 PM, Kevin Dente <kevinde...@gmail.com>

[Chad Lee]

I agree with Kevin that making something like that configurable would hurt the portability of the code.  Not to mention the difficulty in having to figure out the different syntax that someone is using when moving to a new code base.

Granted, it probably won't be a problem 90% of the time given that most people won't change the defaults, but given that, why even make it an option?

Again, I think it is too much risk for not much value.  I'm fine with ${H()}.

[Louis DeJardin]

Probably would need to be in <spark> config or ISparkSettings for the
settings to be available before the parse occurs. Which is a shame - I
really like how putting <use namespace> and <use assembly> in
_global.spark reduces dependency on web.config.

Don't other things like partials and macros also affect the
portability? If I have <rounded>stuff</rounded> that won't work
without _rounded.spark.

I agree config is suboptimal, and it does head down a configuration
over convention path, but who can say what helpers are most useful.
That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both
supported - it's not that there's anything right or wrong about the
alternatives and supporting both doesn't negatively impact either one.

I'd lean more towards making it configurable than adding universal
meaning to a number of different syntax.

On the other hand it would be pretty easy to turn your spark files
into a mass of unreadable shortcuts. Okay - how about moving away from
the idea of using punctuation, and instead use small expansion marks
that start with $...

<expansions>
<add mark="$" expansion="{0}"/>
<add mark="$$" expansion="H({0})"/>
<add mark="$H" expansion="H({0})"/>
<add mark="$A" expansion="Html.AttributeEncode({0})"/>
<add mark="$L" expansion="Html.ActionLink({0})"/>
</expansions>

${Html.TextBox("blah")}
<span title="$A{product.About}">$H{product.Name}</span>
$L{"Go back", "index", "home"}

To encourage portability and convention you could provide a small set
of compatible defaults for monorail and asp.net mvc, like the ones
above. Configuration only needed to extend or modify defaults, if you
never use them they won't affect anything, and still reads like ${}
visually and hopefully more intuitive than punctuation.

(Not trying to pitch the idea of course, just talking it through.)

I wonder if you would apply the same idea to <%= %>?

<add mark="%=" expansion="{0}"/>
<add mark="%H" expansion="Html.Encode({0})"/>
<add mark="%L" expansion="Html.ActionLink({0})"/>
<add mark="%Link" expansion="Html.ActionLink({0})"/>

<%H product.Name%>
<%L "Go Back", "Index", "Home" %>
<%Link "Go Back", "Index", "Home" %>

On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
> I agree with Kevin that making something like that configurable would hurt
> the portability of the code.  Not to mention the difficulty in having to
> figure out the different syntax that someone is using when moving to a new
> code base.
>
> Granted, it probably won't be a problem 90% of the time given that most
> people won't change the defaults, but given that, why even make it an
> option?
>
> Again, I think it is too much risk for not much value.  I'm fine with
> ${H()}.
>

[Chad Lee]

I agree config is suboptimal, and it does head down a configuration
over convention path, but who can say what helpers are most useful.

You can! :)  I'd rather see methods like this hard-coded than defined in configuration.

This thread started out with trying to find a way to get the default ${} syntax to be html encoded so you wouldn't have to think about it - your output would just automatically be encoded.

What we are talking about now is just providing user-defined shortcuts for already-short method calls.  Again, I don't see the value.  I think it would take more development time than it is worth.

That is just my 2 cents.

[Kevin Dente]

This *feels* very similar to the macro concept that's already there
(granted, I'm very new to Spark, so maybe I'm off-base here). Would it
make sense to extend the existing capability to support this kind of
macro expansion?

[Louis DeJardin]

Well the macro is more about a way to create helper-like functions
with the spark dialect. Helps keep html concatination out of cs.

But it is true if you add a base page class to a project you can add
any functions like H() there - so that would probably be a better way
to add ${L(...)}

So only thing you'd save are the parens.

[Louis DeJardin]

Which brings us all the way back to the original suggestion! :)

How does double-dollar to htmlencode strike you?

${Html.TextBox("foo")}
$${product.Description}
^{product.Description}
@{product.Description}
+{product.Description}

I'm not sure if any in particular really stand out to me. I might lean
towards $${expr} since I'm already used to seeing ${expr}. There's
also precedent to using two-character $ syntax with $!{expr} to
silence null exceptions.

On Dec 17, 9:54 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> Well the macro is more about a way to create helper-like functions
> with the spark dialect. Helps keep html concatination out of cs.
>
> But it is true if you add a base page class to a project you can add
> any functions like H() there - so that would probably be a better way
> to add ${L(...)}
>
> So only thing you'd save are the parens.
>

[subnus]

I think that the double-dollar way is the way to go

[Артём Тихомиров]

I think that signs as alias for macro functions would be much more convinient. It would be the way to save a handful of annoyance. For example:

%{'jquery-ui-1.6b.min', 'i18n/ui.datepicker-ru', 'jquery.clockpick.1.2.4.min') 

insted of:

${jQuery("jquery-ui-1.6b.min", "i18n/ui.datepicker-ru", "jquery.clockpick.1.2.4.min")}


This could be declared like this:

<macro name="jQuery" alias="%"  files="params string[]">
...


You could parse such constructions as generic "alias constructions" and resolve em in codegen time (sorry if I misunderstood Spark internals).

[Артём Тихомиров]

Even for existing functions such as H it would be simple to create macro-wrappers:

<macro name="Escape" alias="+" html="string">
  ${H(html)}
</macro>

[Louis DeJardin]

That would be nice but unfortunately it couldn't be defined inside of
the spark files because the information would need to be used by the
first stage parser. The breakdown of the files text happens before the
macros are known.

> ...
>
> read more »

[Kevin Dente]

I'm probably alone on this one, but I think I'd prefer something
completely *different* than ${} - $${} is similar enough that I could
see accidentally using ${} and not noticing. Of course, you have an
existing framework to fit this into, so if using a 2-character
expression fits the model better, I can understand that.

[petemounce]

Personally, I like the idea of being able to define customised mark-
aliases. On top of that, to fit in with convention over
configuration, why not ship Spark with sensible-default ones already
defined? There would then be little need to customise them, but the
option would exist for special needs.

Here, I would be in favour of the breaking change of making ${} HTML-
encode by default. I read Rob Conery's blog post on the perfect storm
botnet, and was frankly aghast. Averting that possibility by default
is, to me, worth the pain of any breaking change.

The effect of the break could be mitigated by defining and release-
noting those sensible-defaults so developers know to use (for example)
$Uf{Url.For(blah)} to replace ${Url.For(blah)}, and so forth.

As an aside, I looked at the Brail docs to see how it handles this,
because I remember reading it way back and seeing something similar.
http://www.symbiotic-development.com/monorail/html/single/index.html#d0e4971
is the relevant passage. It allows output methods to be defined much
like has been described here for ${H("foo")}.

While looking at it, I remembered the half-remembered thing Brail does
with the ! syntax for ignoring nulls; see
http://www.symbiotic-development.com/monorail/html/single/index.html#d0e4995
. This is something I would find useful, too.

Regards
Pete

> > > >> > > > >>> > > considered making Spark encode...
>
> read more »

[Артём Тихомиров]

As I understood, parsing and codegen is separated in time. You could parse fixed (on language level) amount of escape symbols as "macro alias X". And then, on codegen stage you could  resolve X or throw exception if it could not be resolved.

[Louis DeJardin]

Well, if there would be a breaking change I'd say the sooner the better. It'd probably be a good idea to provide a config switch to disable html.encode for transition or personal preference. So looking at it from the other direction how about !{ } or $${ } for unencoded output?

${expr}
Output.Write(H(expr));

!{expr} or $${expr}
Output.Write(expr);


!{expr} might work well... Draws your attention to the fact you're opting into writing out raw (!) html. Also fits with the punctuation-ness of ?{cond}. Not sure if $${} would be needed. Any thoughts?


Like Артём mentioned you could make the assumption any $X{foo} would turn into Output.Write(X.foo); and let the compiler throw errors if X didn't mean anything.

That said, to me $Html{ActionLink("foo", "bar")} is less readable than !{Html.ActionLink("foo", "bar")} and not any shorter. If there was anything along those lines I'd probably still prefer something configurable like $H{ActionLink("foo", "bar")} or $Link{"foo", "bar"}.

[Артём Тихомиров]

There is another opportunity, though it could hurt performance purists. It's passable to have some kind of dynamic dispatch for such an aliases.

Any way it's always better to have generic mechanism then a set of on-demand features.

[petemounce]

I would like the !{expr} syntax for "output unencoded". I don't like
the $${expr} because of the potential for typos / misreading.

On Dec 21, 6:37 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> Well, if there would be a breaking change I'd say the sooner the better.
> It'd probably be a good idea to provide a config switch to disable
> html.encode for transition or personal preference. So looking at it from the
> other direction how about !{ } or $${ } for unencoded output?
>
> ${expr}
> Output.Write(H(expr));
>
> !{expr} or $${expr}
> Output.Write(expr);
>
> !{expr} might work well... Draws your attention to the fact you're opting
> into writing out raw (!) html. Also fits with the punctuation-ness of
> ?{cond}. Not sure if $${} would be needed. Any thoughts?
>
> Like Артём mentioned you could make the assumption any $X{foo} would turn
> into Output.Write(X.foo); and let the compiler throw errors if X didn't mean
> anything.
>
> That said, to me $Html{ActionLink("foo", "bar")} is less readable than
> !{Html.ActionLink("foo", "bar")} and not any shorter. If there was anything
> along those lines I'd probably still prefer something configurable like
> $H{ActionLink("foo", "bar")} or $Link{"foo", "bar"}.
>
> On Sun, Dec 21, 2008 at 8:13 AM, Артём Тихомиров <ar...@tikhomirovs.ru>wrote:
>
> > As I understood, parsing and codegen is separated in time. You could parse
> > fixed (on language level) amount of escape symbols as "macro alias X". And
> > then, on codegen stage you could resolve X or throw exception if it could
> > not be resolved.
>

> > On Thu, Dec 18, 2008 at 11:37 PM, Louis DeJardin <Louis.DeJar...@gmail.com

> ...
>
> read more >>