- [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.