I have previously written an article related to Building a Web Server in Go: Handling Page Requests, and I recommend that it is read in conjunction with this article (though it is not necessary to properly understand this post).
In Go, pretty much every webpage is “handled” or served via a “http.HandleFunc(“Page”, HandlerName),” there are other ways of doing this, and quite often you can simply call: “http.HandleFunc(“/”, viewHandler).” However, in the case that you have a different layout and special user requests (such as a user login) it makes sense to have a very specific http handler. Such is the case with user input, which require special database entries, other encryption functions, or login credentials and reloading of pages.
HTML Form
An HTML form is pretty standard, and in the case of a password may look something similar to the following:
In the above code snippet, the email input field is stored as plain text and it can be viewed as typed. By contrast, “pwd” is a password input type, meaning it is masked upon input (i.e. there are * for each character you input). The pwd is visible to the server and unsecured internet connections, but not to people looking over your shoulder.
Go – loginHandler
Once the user inputs values into the form and presses submit the form then needs to be handled, Go does this using a handle function. In this case, the code I am using is from a basic web server my friend Robb Seaton and I wrote. We use functions from several other libraries we wrote, but is should be clear:
Generally speaking you do not need to send a web cookie to the user every time they fill out a form, nor do you need to check their credentials (unless they are logging in). This would make the handler much simpler for handling something such as comments, or posting a blog article. However, I chose this example because you can see how abstracting the users identification, cookies, encryption into a separate library can make the world of difference in how difficult it is to read the code.
Further, by abstracting most of the heavy lifting into their own libraries you can have multiple unique handler functions that are relatively simple to read and use (and therefore more sustainable for coding projects). In our project, we had a few more than we needed, but it was still relatively simple and it covered most of the user input:
In our case we did not have any user comments or networking, though it would be trivially easy to add.
Database Injections
At this point we do not have any error checking against injections or other database attacks. If we were going to protect against database attacks it would likely go in a separate library, which would take inputs and remove any possible attacks or remove the comment/user input all together. All the programmer would then have to do is run something such as,
As you can see it would be a relatively easy inclusion (granted the attackChecking would need to be written). If you would like to see any code related to this article feel free to view the github, I would also like to mention Robb Seaton as a developer who wrote about half the code for the project.