Setting Up express-session

Objectives

By the end of this lesson, you should be able to:

• Install and configure express-session
• Explain what each core configuration option does
• Read and write values on req.session

💡 Why this matters: The last lesson covered how sessions work conceptually. This lesson wires that concept into a real Express app, the middleware every route in this module builds on.

⚠️ A note on verification: every snippet and every output in this lesson was actually run.

Installing express-session

npm install express-session

Basic Setup

const express = require('express');
const session = require('express-session');

const app = express();
app.use(express.json());

app.use(session({
  secret: 'dev-only-secret',
  resave: false,
  saveUninitialized: false,
  cookie: { maxAge: 1000 * 60 * 60 }
}));

Reading each option:

• secret, used to sign the session ID cookie, so it can’t be tampered with. In a real app, this comes from an environment variable (Databases & ORMs for Node.js, Module 1’s environment-based configuration pattern), never a hard-coded string like the placeholder above.
• resave: false, don’t re-save a session to the store if nothing in it changed, avoids unnecessary writes.
• saveUninitialized: false, don’t create a session for a visitor who never actually logs in, avoids empty sessions piling up.
• cookie: { maxAge: ... }, how long the session cookie stays valid, in milliseconds, one hour here.

Reading and Writing req.session

Once this middleware is registered, every request handler gets a req.session object, automatically tied to the right session via the cookie:

app.post('/api/v1/test-session', (req, res) => {
  req.session.visits = (req.session.visits || 0) + 1;
  res.json({ visits: req.session.visits });
});

Anything assigned to req.session (like visits here) is automatically saved, and available on the next request from that same browser, express-session handles the storage and the cookie entirely, nothing here needs to be sent back manually.

Where Sessions Are Stored by Default

Without further configuration, express-session stores sessions in memory, in the Node process itself. This is fine for development and for this course’s exercises, but has a real limitation worth knowing: an in-memory store is wiped on every server restart, and doesn’t work across multiple server instances (a real production deployment running more than one copy of the app). Production apps typically point express-session at a shared store instead, Redis is the most common choice, configured through the same session() call with a store option, this course’s exercises use the default in-memory store to keep the focus on authentication itself.

Try It

1. Install express-session, and set up the basic configuration shown above.
2. Build the /api/v1/test-session route, and confirm the visits count increases across multiple requests from the same client.
3. Confirm a request from a different client (a fresh supertest request, not using an agent, covered next lesson) gets its own separate count, starting at 1.
4. Explain, in your own words, why saveUninitialized: false avoids creating sessions for visitors who never log in.

Recap

• express-session middleware attaches a req.session object to every request, automatically tied to the right session through a signed cookie.
• secret, resave, saveUninitialized, and cookie.maxAge are the core configuration options, each with a concrete effect on behavior.
• By default, sessions live in memory in the Node process, fine for development, but a real production app needs a shared store like Redis instead.

Next lesson: a real login and logout flow, and protecting a route so it only responds to a logged-in session.