From the course: Advanced Express

Understanding cookies and sessions

From the course: Advanced Express

Start my 1-month free trial

Understanding cookies and sessions

“

- [Instructor] Before we authenticate a user, we have to talk about how to recognize them later. Well, let's say it more generally, how can we store information about one individual user in the session on the server? For that we need cookies and some kind of session management. Let's look at the typical authentication flow, very similar to what we will build in this chapter. We have a browser and a server and let's also conceptually create the box for the app that is served by the server and also one for the database. The browser sends a post request with some form data like e-mail and password, tool slash, log in. On the server we will now try to authenticate the user and if the login is valid, recreate the session that maps the user logged in to some random identifier. Inside the session we can now set arbitrary data that we want to associate with this user like the user ID to fetch the user from the database for subsequent requests. The server will now send back some HTML to the browser like the thank you page for logging in, and additionally, it sends a special header called Set-Cookie. If a browser gets such a header, it will store this cookie and will send it from now on with every request to the server like forward slash account. Every session has a unique identifier called Session ID. On the server we can then use this identifier to load the session, and in this session we will find the previously stored user ID and we can use it to fetch the user from the database. What's important here, is that the session identifier has to be something like a random hash that can only be mapped back to the user by the server. Why? A very simple and very wrong example would be to use the email address of the user as a Session ID. As cookies can be freely manipulated by the client, anyone that knows the email address of the user could now become this user. The same applies to using incremental ID's, account numbers, or whatever information that can easily be guessed or tried out by a brute force of text. There are a few properties that can be sent with a cookie. Additionally, to the cookie value a key-value pair, we can set an expiration date. If this is omitted, the cookie will be deleted when the browser closes. We can tell that this cookie will only be sent by Qualys secure connection, means SSL. Or that the cookie cannot be read by a JavaScript on decline. To make express read cookies, we need a middleware called Cookie Parser. It's part of express, but needs to be installed separately. If it's in place, it will look for cookie headers in the raw request headers and make them available in request cookies. Now we need a way to store and manage the session data and Express provides a module for that. It's called Express Session. Express Session, by default, stores your session information in memory, but this is not recommended in production. Mostly because only the process that stores the session can read it afterwards. This solution will start to work as soon as you scale up to multiple processes, like with a Clustal module or even scale out to different servers. Luckily, Express Session lets you define storage back-ends and there is a variety of modules available for that. As we are already using Mongo DB, let's store the session there. For that we will use connect Mongo. Then all we have to do is add Express Session bio middleware. Connect Mongo also supports reusing mongoose connections and that's ideal for us. But that was enough theory for now, we will now implement session management in our Express application.

Contents