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 http.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 http.SetCookie() function to write the cookie to the response.
In the GetFlash() helper we use the r.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 this package instead:
If you enjoyed this article, you might like to check out my recommended tutorials list or check out my books Let's Go and Let's Go Further, which teach you everything you need to know about how to build professional production-ready web applications and APIs with Go.