Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The lack of example code in the security section should be a worry to all.

It isn't hard to prevent SQL injection if you use parameterized SQL statement rather than using string concat, and whilst examples of this are trivial they shouldn't be skipped.

In the XSS section it mentions filtering and checking inputs, but does not mention sanitization and does not give any examples. In the aversion to use any non-standard package it also does not mention https://github.com/microcosm-cc/bluemonday or anything similar (I am the author of bluemonday - a HTML sanitizer in the same vein as the OWASP Java HTML Sanitizer).

There is some sample code, in the Filtering section, but this only demonstrates the use of a fixed range of inputs in determining a filter, and then a regexp to check the input matches a format.

Beyond the security, where the theory is at least known even if a demonstration on how to implement it is lacking... the entire guide misses out on demonstrating templates to their fullest, and specifically using a map of functions to provide the equivalent of Django's TemplateTags.

In fact, the missing link for most Go developers who are building web apps, and for those coming from outside Go, are template tags. Most Go devs I know (who seem more systems focused) don't even realise that this stuff exists: https://golang.org/src/text/template/examplefunc_test.go



Using string-based templating in general is a really bad practice, as it leaves the door wide open for XSS, SQL injection, etc. Sanitizing inputs, while often cited as the proper thing to do, isn't addressing the root problem: that we're using templating systems that don't use proper data types and thus can't automatically DTRT when rendering.

See http://www.more-magic.net/posts/structurally-fixing-injectio... and https://www.gnu.org/software/guile/manual/html_node/Types-an... for further explanation.


Interestingly, html/template does actually handle some stuff like this. Pass html in a string as a field into html/template, and it'll escape all the html automatically. In order to get the html to actually render, you have to pass it in as a `template.HTML`. There are variants of the `HTML` type for different places, including html attributes and javascript code.



Templates are definitely the most lacking aspect of Go in my experience. Templating exists and works but in my usage at least has felt very clunky.

It could be that I just haven't come across any resources that do a good job of explaining their strengths. I see so many comments from people who seem genuinely excited about Go's built in templates that my assumption is always that I'm doing something very wrong.


They are woefully undocumented.

Well, that perhaps isn't fair... fairer would be to say that there isn't an authoritative set of examples showing how people can achieve things similar to something like Django templating or Rails templating. It is actually fairly effortless to nest templates, extend them with custom functions, and all of the things one would need to do.

Probably one of the best resources is Hugo: https://gohugo.io/templates/go-templates/ and the funcs (template tags) they ship.

That isn't too bad at all, but the snippets and examples are so small that it's hard to really see what the value is and how it all glues together to create nice readable templates.

Anyhow, the key place to look at template tags would be:

1. Hugo's source code for template funcs: https://github.com/spf13/hugo/blob/master/tpl/template_funcs...

2. Hugo's creation of the func map: https://github.com/spf13/hugo/blob/master/tpl/template_funcs...

3. Hugo's documentation on the funcs: https://gohugo.io/templates/functions/

Those three things, viewed as one, should allow any Go dev to extend templates to do whatever you want them to do.

Hugo have been very "functional" in their choice of template tags, but there's huge scope for new packages to deliver more aesthetic tags, or tags for localization, to humanise time and plurals, basically to provide a core resource of tags similar to https://docs.djangoproject.com/en/1.9/ref/templates/builtins... so that each dev doesn't implement their own.


One thing I haven't found how to do is telling a template to insert itself into a parent template, e.g. (pseudotemplate code)

  <extends main_with_feature_x>
  
  <define title {{something}}/>
  
  <define body>
  ... body goes here...
  </define>
etc etc

Including everything in every template just reeks of old school php. (Yes, I defend modern php : )


Then you didnt look very hard http://play.golang.org/p/DHk9iKnOMO


?


You can use the template function to include another named template.


I don't know if I understand it correctly but I'm specifically looking to avoid every template looking like this: (old school php like)

  <?php include (header.php)?>
  
  ... business logic goes here...
  
  <?php include (footer.php)?>


I agree it is much nicer to have a layout template which includes your view templates (ala rails and many other systems), rather than including header/footer in each template. Yes you can do this, I handle this by having a layout template which includes a key for content, and rendering each view into its own template (without header/footer) which then goes into the content key of the layout. This is pretty straightforward to do though apparently not a usage they anticipated.

They've recently introduced the concept of blocks too which is an attempt to solve this though it looked pretty clunky to me last time I looked. See this discussion from author of hugo asking how to use it (always a bad sign!):

https://github.com/golang/go/issues/14285

I think I prefer just rendering the view separately and then rendering it into the layout, it's easy to do.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: