<p>I created a basic web application in Golang to learn how to use each of the internal packages with a few external packages. I'd love to hear how you would make this web app better.</p>
<p>All feedback is welcome. Let me know if you have any suggestions, questions, or criticisms. If something is not idiomatic to Golang, please let me know know so we can make it better.</p>
<p>To sum up what is done in the web app: it loads a config file through JSON, starts a gorilla session, connects to a MySQL database, precompiles templates, loads template functions, attaches middleware, assigns routes. There's also support for flash messages, CSRF protection, and basic brute force protection. The front end is done in Foundation. Thanks!</p>
<p><a href="https://github.com/josephspurrier/gowebapp">https://github.com/josephspurrier/gowebapp</a></p>
<hr/>**评论：**<br/><br/>mwholt: <pre><p>Thank you for not making another framework.</p></pre>Zilog8: <pre><p>This is pretty sweet! The only suggestion I can possibly offer is including HTTPS as a configurable option.</p></pre>motojo: <pre><p>That's a great idea. I shall!</p></pre>qu33ksilver: <pre><p>One small question. I see that you have written all the routes in gowebapp.go.</p>
<p>What if I had more routes, how would you have split the routes across multiple files and namespaced them ?</p></pre>motojo: <pre><p>Good question, you could use an init() function like this and then register all the routes: <a href="http://stackoverflow.com/a/19373893" rel="nofollow">http://stackoverflow.com/a/19373893</a>.</p></pre>mT5nKbHe: <pre><p>Thanks for this. There are not enough examples of basic application structure suggestions. </p></pre>gohacker: <pre><p>I'm sure you're aware that using a cookie to store the number of login attempts is a weak protection against brute-force attacks.</p></pre>motojo: <pre><p>Yeah, you're right. All a hacker would need to do is delete their cookie every couple attempts and they could keep attacking. What method would you suggest to protect against brute force? Save the attacking IPs in a table? Link up with fail2ban to block IPs?</p></pre>mwholt: <pre><p>There's <a href="http://badactor.org" rel="nofollow">BadActor</a> to help with that.</p></pre>motojo: <pre><p>Cool, didn't know about this one.</p></pre>gohacker: <pre><p>I wouldn't use tables. Something like Redis is better.</p>
<p>fail2ban is good too.</p></pre>motojo: <pre><p>Thanks, I'll play around with a few and see what makes sense.</p></pre>jerf: <pre><p>"Brute force" is not a thing you can protect against; it's a class of attacks. You really need to split your analysis of the problem up into multiple pieces before you can get anywhere with it.</p>
<p>And to be honest, the more I learn about brute force attacks, the less I care about trying to defend against them. The only one I still find myself really caring about is brute force password checks, and probably the best thing to do about that is use bcrypt set with a decent difficulty, so that even if you hammer the server, you're limited to an uselessly low rate of checks. Trashes the server in the meantime, but there's less you can do about that than you initially think. (Won't say there's "nothing", exactly, but all your obvious ideas don't really work at scale, or work hardly any better than what bcrypt is already doing. bcrypt used properly already prevents more that a few dozen password attempts per second per core by brute physics.)</p>
<p>You simply can't prevent brute-force bandwidth exhaustion at the web framework level... by the time it's reached the web framework it's already too late.</p></pre>motojo: <pre><p>Yeah, I know what you mean. I like the idea of redis or BadActor coupled with a captcha after a few bad attempts. I know Google used a captcha a while ago, no idea if they still do it now. I just know you need some type of protection because you're right, it can trash your server while you're coming up with a fix.</p></pre>Dont_Reddit_Me: <pre><p>Thanks for sharing.</p>
<p>I have a question not necesarily directed to OP: does gorilla/sessions really need CSRF protection? It handles variables/parameters behind the scenes, not via URL queries and such. Although you could, but it is a bad practice</p></pre>motojo: <pre><p>gorilla/sessions is susceptible to CSRF attacks. CSRF could be triggered by clicking a harmless looking submit button that is actually a malicious form. The only requirement is that your browser is authenticated into some type of known account like your bank.</p>
<p>Example from <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)" rel="nofollow">https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)</a></p>
<p>I send you an email that says your bank account has been hacked so you login to Bank of America. Everything looks fine so you go back to the email to read. The email says, "Click this button to read about the details of the hack". Well, the button is actually a submit button for a malicious form. The form looks like this:</p>
<pre><code><form action="http://bank.com/transfer.do" method="POST">
<input type="hidden" name="acct" value="12345"/>
<input type="hidden" name="amount" value="100000"/>
<input type="submit" value="Click this button to read about the details of the hack"/>
</form>
</code></pre>
<p>When you click on the button, the form sends a POST request to your Bank website and transfers $100,000 to account number 12345. Even though gorilla/sessions saves all the information on a backend filesystem or in a cookie that is encrypted, the attack simply utilizes the authenticated web session through your browser. If your bank used CSRF protection by requiring a token in the form above, the request would have failed. This is an oversimplification because it was designed to show you that regardless of where gorilla/sessions (and other session libraries) store their data, the vulnerability still exists.</p></pre>
