I still don’t understand why automatic escaping makes html/template impractical for the purpose you were describing. Is it because the blog post would be HTML rather than plain text? In that case, you would need to convert it to the template.HTML type before passing it to the template, and it would be rendered without escaping. (Then sanitizing the HTML to prevent XSS would be up to you, of course.) The html/template escapes content by default, but there are ways to get around it if you tell it you know what you are doing.
Andy > On Sep 13, 2017, at 7:01 PM, Karv Prime <karv.pr...@gmail.com> wrote: > > It = html/template > "The purpose" = the one I thought I could use it for and described above. > > Am Donnerstag, 14. September 2017 03:58:02 UTC+2 schrieb Andy Balholm: > Why does automatic escaping make html/template completely impractical? (Or > did I guess the antecedent of “it” incorrectly?) > > Andy > >> On Sep 13, 2017, at 4:30 PM, Karv Prime <karv....@ <>gmail.com >> <http://gmail.com/>> wrote: >> >> Thank you for the heads up. So it is completely impractical for the needed >> purpose. >> >> In that case it would be truly bad. That's why user input should always be >> checked. Such a blogpost shouldn't even come that far. ^^ Either it's >> escaped before it gets to the database (not truly necessary due to prepared >> statements etc., but depends on the use case scenario), but at least it >> should be escaped before it hits the visual representation. >> >> Let's stay with the blogpost example to give some further insight and assume >> the following [folder]/file structure: >> [site] >> - site.html (the full site, but without nav, and main, as well as data that >> depends on which page is shown, language, etc. (html lang, title, keywords, >> etc.) >> - nav.html (only the navigation, which isn't depending on anything, but >> exists as its own module) >> - main.html (main content - in our case the blog - that has different >> blogposts) >> [modules] >> - blogpost.html (a singular blogpost and how it should look like) >> >> So the application should at first stick together site, nav, and main. If >> that happens at runtime or if it creates a template beforehand is a matter >> of optimization, but doesn't really matter in our example. As the user >> requested the page in Latin, lang, title, keywords, etc. are filled in >> accordingly. Up to that point any code injection could be possible but then >> there are other security concerns as until then no user data has been used. >> We have 5 blogposts as our blog came to live a day ago and up to now only >> spambots were here. But user entries are user entries, so let's parse them. >> Take the blogpost.html file and fill <div class="username"></div> as well as >> <div class="userpost"></div> with their content: Escape the content, then >> fill it in the same way as innerHTML from JS works. Put these 5 blogposts >> into main and send it to the user. >> Another user clicks "blog" in the navigation but has JS activated - so it >> only loads the main content. Again the 5 blogposts, but not the full site. >> Some other user is active on the blog, but gets updates every 10 minutes or >> due to server side events - as the previous user complained about the >> botposts he now only gets a representation of blogpost.html sent with the >> content to be prepended before the other posts. >> >> Yes, one could realize that solely with templates. But everytime just a >> little thing has to be changed (i.E. another navigation link added) someone >> has to touch the whole site.html file (GIT be praised, but nonetheless it's >> not that good for really big sites, so a separation is at least sometimes >> practical). The downside is that every HTML guy needs to learn the "how to >> templating in language X", be it Golang, Twig, Smarty, ... instead of just >> creating plain simple HTML which can be manipulated by the code via the HTML >> DOM. And if there's something missing it creates a warning which is >> practical too (as, if the full site without the dynamic stuff gets stitched >> together beforehand from some kind of easy maintainable [meta] page, it >> could stay with the previous version until the oversight is solved, or >> whatever one wants to do with that information). And the problem "some >> coders could actually forget to check user input" can be solved with taint >> checking (if the content comes from a "secure" source (i.E. a .html file) >> there is no need for a warning, but if it's from a database all hell should >> break loose) - but as files could under certain circumstances also be >> user-created (i.E. some esoteric database where every blog entry is a file) >> there's a problem here. One can't prevent coders from making mistakes. PHP >> tried, it failed. ^^ Java has no taint checking if user data is injected >> into a SQL query, Perl and Ruby have it. Maybe the solution would be to >> allow a coder to choose between an unescaped innerHTML and an escaped one. >> >> Am Donnerstag, 14. September 2017 00:43:10 UTC+2 schrieb Andy Balholm: >> You may not be aware that the html/template package does automatic escaping. >> So if a template has <div id=not-so-secure-blogpost>{{.Blogpost}}</div> and >> Blogpost contains <script>alert(“Pwned”)</script>, the result will be >> something like <div >> id=not-so-secure-blogpost><script>alert("Pwned")</script></div> >> >> Assigning to the div’s innerHTML would be bad in this case, but appending a >> text node to the div would be safe. >> >> Andy >> >>> On Sep 13, 2017, at 2:10 PM, karv....@ <>gmail.com <http://gmail.com/> >>> wrote: >>> >>> I don't know why it's unclear, what I'm proposing, but I'll try a 2nd time: >>> >>> Something similar to: http://php.net/manual/en/book.dom.php >>> <http://php.net/manual/en/book.dom.php> >>> >>> Or, even simpler: >>> - Find Tags, IDs, Classes, etc. in an HTML document. >>> - Something similar to Element.innerHTML to put content into these tags >>> (https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML >>> <https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML>) >>> - Something similar to Element.setAttribute to change attributes of DOM >>> elements >>> (https://developer.mozilla.org/en-US/docs/Web/API/Element/setAttribute >>> <https://developer.mozilla.org/en-US/docs/Web/API/Element/setAttribute>) >>> - Maybe some validation if the HTML DOM is correct >>> - Possibly some sanitation to check if there are any empty tags or empty >>> tag attributes (i.E. empty content on some meta tag) >>> >>> In short: Load some HTML code, and manipulate the HTML Document Object >>> Model instead of being dependent on placeholders. >>> >>> Yes, a standard library shouldn't do everything. But same goes with >>> templating, so that isn't really an argument against implementing it into >>> the codebase if one of the main foci of Golang is the Web. >>> >>> I wasn't ignoring the Security Model. If someone uses Golang to create a >>> comment section in the web, the same could happen with Templates, if the >>> developer isn't aware of possible security issues. There is no difference >>> if some unchecked user content is injected into <div >>> id="not-so-secure-blogpost>{{blogpost}}</div> or <div >>> id="not-so-secure-blogpost></div>. So I really don't see where >>> "html/template" avoids this issue if some coder doesn't watch out how user >>> content is handled. Escaping the user content (or other security features) >>> can be implemented too, yes - but that should be some other package imho. >>> >>> Kind regards >>> Karv >>> >>> Am Mittwoch, 13. September 2017 21:58:47 UTC+2 schrieb Egon: >>> If you want to manipulate HTML files then there is >>> https://godoc.org/golang.org/x/net/html >>> <https://godoc.org/golang.org/x/net/html>, >>> but it comes with all the dangers of potential injection attacks and so >>> on... which "html/template" avoids. >>> Writing something that injects into the specific nodes and afterwards >>> encodes shouldn't be a big problem. >>> >>> If you want to write HTML directly from code then writing a simple html >>> encoder with the necessary models >>> isn't too complicated >>> (https://github.com/egonelbre/exp/blob/master/htmlrender/main.go >>> <https://github.com/egonelbre/exp/blob/master/htmlrender/main.go>) >>> >>> But the huge con you are ignoring is the Security Model. >>> (https://rawgit.com/mikesamuel/sanitized-jquery-templates/trunk/safetemplate.html#problem_definition >>> >>> <https://rawgit.com/mikesamuel/sanitized-jquery-templates/trunk/safetemplate.html#problem_definition>) >>> >>> Anyways it's unclear what you are proposing or needing: in general standard >>> libraries shouldn't do everything >>> and probably this, whatever it is, should belong to a 3-rd party package. >>> >>> + Egon >>> >>> On Wednesday, 13 September 2017 22:02:02 UTC+3, Karv Prime wrote: >>> Hello, >>> >>> I only recently found my way to go. I'm a (former?) fullstack web-dev and >>> as I ran into a PHP related problem (DOMDocument not working with HTML5 >>> tags, I'd choose another solution stack if the language wouldn't be a fixed >>> point in history) I was looking if Go already has a good way to manipulate >>> HTML files. The templating is fine, but in my humble opinion there's a >>> problem... >>> >>> Problem: IMHO templating in the current form is flawed. To insert >>> placeholders (i.E. "{{.nav}}") probably isn't an optimal solution as it >>> just tells the code "hey, act upon me". It seems to be a shallow solution >>> to prevent code-mixins, but fails to really separate the concerns. >>> >>> Solution: If there would be a Go package to directly manipulate the DOM it >>> would be very helpful to separate Markup and Code. The code would act onto >>> the markup file (*.html) to create the page/site/module/... (whatever is >>> needed). >>> >>> Pros: >>> - Frontend devs could create their own pages, modules, etc. without >>> thinking about any special tags they'd need. >>> -> '<main></main>' instead of '<main>{{.content}}</main>' >>> -> '<meta name="description" content="">' instead of '<meta >>> name="description" content="{{.description}}">' >>> - Error/Exception if some tag/id/class/... has not been found instead of >>> admins possibly not knowing about it. >>> -> You can act upon it and tell the users "Oops, something went wrong, >>> we're looking into it." so they know that the current state of the site >>> isn't what they should see. >>> -> Better an empty element (and the admin knows about it) instead of users >>> seeing placeholders. >>> - It's easier to avoid any problems with funny users trying to trick the >>> system. >>> - In theory faster than templating solutions (untested claim, so there's a >>> big questionmark)? >>> - It prefers modular frontends (main site, nav, main content, reusable >>> modules (i.E. for items on a sales platform)) instead of a single file with >>> placeholders >>> - It prefers cleaner code and true SoC instead of the ofttimes preferred >>> workflow "just a little HTML in the code to create each item faster" or >>> vice versa. >>> - ... >>> >>> Cons: >>> - If there are elements unknown to the backend-devs, they will probably >>> stay empty >>> -> Possible solution could be some kind of taint-checking for empty >>> elements after page creation >>> - "Duplicate" code if there's frontend-scripting that is changing >>> parameters accordingly to AJAX results, but that's almost unavoidable. >>> - Probably more communication needed between backend- and frontend-devs >>> -> Possible solution, the aforementioned taint-checking, to see these >>> problems in testing, if they should arise >>> - ... >>> >>> Feel free to contribute your thoughts, other pros/cons, etc. :) >>> >>> Kind regards >>> Karv >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to golang-nuts...@ <>googlegroups.com <http://googlegroups.com/>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
