Not sure how to structure your Go web application?
My new book guides you through the start-to-finish build of a real world web application in Go — covering topics like how to structure your code, manage dependencies, create dynamic database-driven pages, and how to authenticate and authorize users securely.
Often in web applications you need to temporarily store data in-between requests, such as an error or success message during the Post-Redirect-Get process for a form submission. Frameworks such as Rails and Django have the concept of transient single-use flash messages to help with this.
In this post I'm going to look at a way to create your own cookie-based flash messages in Go.
We'll start by creating a directory for the project, along with a flash.go file for our code and a main.go file for an example application.
In order to keep our request handlers nice and clean, we'll create our primary SetFlash() and GetFlash() helper functions in the flash.go file.
Our SetFlash() function is pretty succinct.
It creates a new Cookie, containing the name of the flash message and the content. You'll notice that we're encoding the content – this is because RFC 6265 is quite strict about the characters cookie values can contain, and encoding to base64 ensures our value satisfies the permitted character set. We then use the SetCookie function to write the cookie to the response.
In the GetFlash() helper we use the request.Cookie method to load up the cookie containing the flash message – returning nil if it doesn't exist – and then decode the value from base64 back into a byte array.
Because we want a flash message to only be available once, we need to instruct clients to not resend the cookie with future requests. We can do this by setting a new cookie with exactly the same name, with MaxAge set to a negative number and Expiry set to a historical time (to cater for old versions of IE). You should note that Go will only set an expiry time on a cookie if it is after the Unix epoch, so we've set ours for 1 second after that.
Let's use these helper functions in a short example:
You can see our flash message being set, retrieved, and then not passed with subsequent requests as expected.
If you don't want to roll your own helpers for flash messages then the Gorilla Sessions package is a good option. This stores session data in a signed (and optionally encrypted) cookie, which stops the data from being tampered with. Here's the previous example implemented with Gorilla instead: