What is a Cookie?
Web cookies, also called HTTP or browser cookies are small pieces of data sent from the web server to the users browser, the users web browser then sends that data back to the web server every time the user loads a page (on the cookies website). In this article we will be describing an authentication cookie, which is used by the browser tell the web server whether or not you are logged in. Essentially, the cookie is used as a key for the user to gain access to their account without having to relogin every time they change a page or return to the website (after a few hours). Cookies used in this way can pose some security risks, however security will not be covered extensively in this article.
Go and Cookies
In Go the “net/http” package already has several functions to set cookies[1], and authenticate cookies[2]. The classic method is to hand a cookie to the user upon logging in with the proper credentials:
In this example, we set the cookie value (cookieValue) to consists of the username plus “:”, and a SHA-2 hash of the user name random number. We then set the cookie to expire in one day using:
time.Now().AddDate( year int, month int, day int)
We then create the cookie using:
http.Cookie{Name: “SessionID”, Value: cookieValue, Expires: expire, HttpOnly: true }
There’s a fair number of variables you can set for the http.Cookie in Go, however we chose the above for simplicity and example purposes. You can find the full list on golang.org. Once we create the cookie and we return it we must save the cookieValue in a database (as well as the users IP address, in a different database) for later authentication. Since, the cookie expires in one day regardless and we do not save the password with the cookie even if a criminal does manage to obtain access to the cookie they would have to use it within a day to obtain access to the account.
An Aside on Security
Although this article is not explicitly reviewing security, security is very important and you must keep it in mind while developing a web server. Putting security features in later could be a pain and potentially impossible without rewriting a significant portion of code or reworking databases. Keeping that in mind, a cookie contains the users username, plus a unique SHA-2 hashed string which works as their temporary key.
If a malicious individual does obtain access to the cookie to keep them from gaining access to the user account we should also ensure that the cookie can only be used from a given IP address. There by ensuring that so long as a hacker does not have both the cookie and a way to spoof the users IP the account is secure.
Further, creating an expiration date and removing the authenticated cookie from the database after a given time can drastically improves security, because there is only a short window to access the account. Unfortunately, the account is only as secure as the users computer and password is at that point and often that is the weakest link in the chain, but we have at least made it reasonably difficult on the server side.
Checking for Cookies
If the user might have a cookie the web server must then check to see if the user has sent one. Using the following function, we can determine if the user is loggedIn with a valid Cookie:
This function uses another function from the package called lookupSessionID we will not cover it at this point because it is a function which uses database calls and is not explicitly relevant to cookies. Suffice to say that all we do in that function is search the database for the saved cookieValue to compare the SessionID given. If there is no sessionID it returns an err and causes the function to return false.
Applying Authenticated Cookies
With those few functions we provide all the basic functionality to authenticate and display user data by using a simple function below (code from handling page requests article):
If the user already has an authorized cookie they do not have the cookie they are redirected to the “/home” page, which I believe in this example is a registration page. If they do have a cookie they are redirected to “/login-succeeded” page, where they can view all of their personal (user defined) data.
If you would like to review the code from this article please feel free to visit my github.