- [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.
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.
- Creating a template engine
- Using MongoDB and Mongoose for user management
- Authenticating and authorizing users
- Adding cookies and sessions to Express
- Creating a login form with Passport
- Handling file uploads
- Storing and serving images
- Deploying an Express application
- Securing an Express application
- Running behind a web server