2 ms·
For the example given, you probably don't need Negroni, Controller or Render. Mux is also possibly surplus, but does tidy up the extraction of values from rout
by buro9 12y ago
For the example given, you probably don't need Negroni, Controller or Render.
Mux is also possibly surplus, but does tidy up the extraction of values from routes a little. But to be totally honest the given example isn't complex enough to start letting Mux shine (multiple values on URLs, a single app serving both http and https).
Blackfriday (for Markdown) is necessary if you want to convert your text input into HTML, though there is a missing dependency here which is Bluemonday.
Bluemonday ( https://github.com/microcosm-cc/bluemonday https://github.com/microcosm-cc/bluemonday ) is a HTML sanitizer and ensures that XSS supplied via the Markdown box is stripped before rendering - I wrote that, it's based on the whitelisting approach as demonstrated by the OWASP Java HTML Sanitizer. Blackfriday even recommends you clean your untrusted inputs: https://github.com/russross/blackfriday#sanitize-untrusted-content https://github.com/russross/blackfriday#sanitize-untrusted-c...
SQLite3 is required, or at least some SQL provider is going to be required if the tutorial wants to fully demonstrate actually saving content and using one of the established interfaces (database/sql) to do so.
So you could reduce this to three deps: Blackfriday, Bluemonday, SQLite3 and stick to core/stdlib http for the actual "web app in Go" stuff.
The other deps, it is debatable whether or not they are essential, certainly the larger web apps will find that they are simplified and easier to read and work with by using some combination of Mux, Negroni and Controller depending on your needs. Render I have not used and do not have a strong opinion on.
- e12e 12y agoThank you so much for this comment about xss. It can be very hard to keep track of how new tools and frameworks handle (or not) xss, sql injection, sessions, ssl pinning, secure cookies etc -- all essential for making usable web apps. Especially with "small simple examples" where the writing is good and the code seems reasonable - it can be hard to believe that the author is showing off dangerously broken code (rather than say, having input run through a whitelist hidden behind a library, and simply not calling attention to it). Without your comment the book would've done me more harm than good - now that I'm aware of the blanks, I can learn with the awareness that I'll have to assume similar errors lurk in the other sections (or: if it looks a little too simple, it's probably because corners were cut, going from simple to simplistic).