New package: HAML templates for Go

846 views
Skip to first unread message

Travis Simon

unread,
Jul 16, 2013, 8:02:44 AM7/16/13
to golan...@googlegroups.com
Hello golangers,

I just wanted to take a moment to introducing Ghaml, a compiler for a Haml-like Html markup language. It is meant to bring the beauty of HAML to the go language while focusing on maximising efficiency. To that end, ghaml templates are compiled into Go code, which is then compiled into your application.

The start of a ghaml template might look like this:
@data_type: string

%html
  %head
    %title= "Hello, ", data
  %body
    %h1= "Hello, ", data

HAML's core principles are:
1) Markup Should be Beautiful
2) Markup Should be DRY
3) Markup Should be Well-Indented
4) HTML Structure Should be Clear

Learn more about Haml here: http://haml.info/

The code is still young, but I'm actively using it and will be debugging along the way. Fortunately, and I credit the go language for this more than anything, it seems to be quite stable and fit for purpose. The underlying parser is heavily based on Rob Pike's parser for the go template code (thanks Rob for the awesome work).


I'm actively seeking contributions and feedback if you want to get involved. 

Regards,
Travis

Rob Pike

unread,
Jul 16, 2013, 4:36:09 PM7/16/13
to Travis Simon, golan...@googlegroups.com
What security guarantees does it offer?

-rob

Travis Simon

unread,
Jul 16, 2013, 6:01:57 PM7/16/13
to golan...@googlegroups.com, Travis Simon
Security from whom? Me, or your own code? From me - everything is compiled into a .go file, so you can audit it (and the source).

From your own code? I don't escape your output against XSS attacks, which I may do on my next checkin, now that you mention it :-)

Rob Pike

unread,
Jul 16, 2013, 6:29:47 PM7/16/13
to Travis Simon, golan...@googlegroups.com
I was thinking about protection along the lines of XSS, as html/template does.

-rob

Travis Simon

unread,
Jul 16, 2013, 8:31:33 PM7/16/13
to golan...@googlegroups.com, Travis Simon
As per Rob's suggestion, the Ghaml templates now protect against XSS attacks using the default '=' operator. For those of you who like to live dangerously, you can still generate unencoded output using the (non-standard) '|' output, as in:

%p= "encoded data: <i>", data, "</i>"
%p| "raw data: <i>", data, "</i>"

would produce:

<p>encoded data: <i>[data]</i></p>
<p>raw data: [data]</p>

Thanks for the suggestion.

David Symonds

unread,
Jul 16, 2013, 9:21:30 PM7/16/13
to Travis Simon, golan...@googlegroups.com
Where do you do context-aware escaping? There are different escaping
requirements based on whether you are in the body, in a tag, in an
attribute value, in an attribute value that is JavaScript, and so on.

Travis Simon

unread,
Jul 16, 2013, 9:36:39 PM7/16/13
to golan...@googlegroups.com, Travis Simon
Er, I'm just calling template.HTMLEscaper and calling it good:

fmt.Fprint(w, template.HTMLEscaper("your", args, "here"))

I'm wondering if that is not enough? I'm struggling to imagine situations where you would have user-generated attribute values, but I guess it could happen.

Is it not enough to suggest that you should do the escaping manually in those situations?

David Symonds

unread,
Jul 16, 2013, 9:48:31 PM7/16/13
to Travis Simon, golan...@googlegroups.com
On 17 July 2013 11:36, Travis Simon <tsi...@gmail.com> wrote:

> Er, I'm just calling template.HTMLEscaper and calling it good:
>
> fmt.Fprint(w, template.HTMLEscaper("your", args, "here"))
>
> I'm wondering if that is not enough? I'm struggling to imagine situations
> where you would have user-generated attribute values, but I guess it could
> happen.

Yeah, that's insufficient. See the complexity that
http://golang.org/pkg/html/template/ grapples with.

> Is it not enough to suggest that you should do the escaping manually in
> those situations?

You could ditch escaping entirely and leave that to the programmer,
but programmers make mistakes. That's why Go has an html/template
package as well as a text/template package.

http://haml.info/docs/yardoc/file.REFERENCE.html#rails_xss_protection
doesn't really give much details on what escaping it is doing. I don't
know HAML, and don't know what Rails is doing behind the scenes.

Travis Simon

unread,
Jul 16, 2013, 9:58:16 PM7/16/13
to golan...@googlegroups.com, Travis Simon
Yup, I've been looking into the html/template code for the last few minutes and see that it is, in fact, more complicated.

So far my code has been context insensitive, but I'm looking into it and writing unit tests to work through as we speak.

Thanks for the heads up.

Nigel Tao

unread,
Jul 16, 2013, 10:02:06 PM7/16/13
to Travis Simon, golang-nuts
On Wed, Jul 17, 2013 at 11:58 AM, Travis Simon <tsi...@gmail.com> wrote:
> Yup, I've been looking into the html/template code for the last few minutes
> and see that it is, in fact, more complicated.

In case you missed the link in html/template/doc.go,
http://js-quasis-libraries-and-repl.googlecode.com/svn/trunk/safetemplate.html
has plenty of reading on the subject.

Travis Simon

unread,
Jul 18, 2013, 6:21:18 AM7/18/13
to golan...@googlegroups.com, Travis Simon
Hi guys,

Just a quick follow-up in case anyone stumbles across this post in the future: my Haml parser now supports proper XSS encoding.

While that code looked like a million laughs to re-implement from scratch (!), I opted to leverage the html/template code.

I have implemented most of the test cases from: .../html/template/escape_test.go in my test page, which look like this:

    #jsStrNotUnderEscaped
      .expected!= `<button onclick='alert(&#34;%3CCincinatti%3E&#34;)'>`
      .actual= "<button onclick='alert(", data.C, ")'>"

and they all seem to be doing sensible things.

So, a big thank you to Dave and Rob and the whole Go team - it is such a pleasure to work in this language.

Regards,
Travis

On Wednesday, 17 July 2013 11:48:31 UTC+10, David Symonds wrote:
Reply all
Reply to author
Forward
0 new messages