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 <javascript:>>
> 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 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
>>
>> 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)
>> - Something similar to Element.setAttribute to change attributes of DOM
>> elements (
>> 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,
>>> 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)
>>>
>>> But the huge con you are ignoring is the Security Model. (
>>> 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.
>> For more options, visit 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 <javascript:>.
> For more options, visit 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.
