express-session vs cookie-parser vs cookie-session vs universal-cookie-express

Managing HTTP Cookies and Sessions in Express Applications

These four packages address different layers of state management in Node.js/Express applications. cookie-parser is a low-level utility that decrypts and parses signed cookies into a JavaScript object, acting as a prerequisite for many other session strategies. cookie-session stores the entire session data directly inside the cookie on the client side, removing the need for a server-side store but limiting payload size. express-session is the industry standard for server-side sessions, storing a lightweight ID in the cookie while keeping heavy data in memory, Redis, or a database. Finally, universal-cookie-express acts as a bridge, allowing Isomorphic (Universal) React applications to access cookie data seamlessly on both the server (via Express) and the client during the initial render.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package	Downloads	Stars	Size	Issues	Publish	License
Package	Downloads	Stars	Size	Issues	Publish	License
express-session	4,255,773	6,359	77.2 kB	97	7 months ago	MIT
cookie-parser	0	2,028	13 kB	32	2 years ago	MIT
cookie-session	0	1,148	24 kB	16	a year ago	MIT
universal-cookie-express	0	215	5.51 kB	4	4 months ago	MIT

Managing HTTP Cookies and Sessions in Express Applications

Handling state in HTTP is fundamental to building modern web applications. While the protocol itself is stateless, users expect their applications to remember who they are and what they are doing. In the Express ecosystem, four distinct packages have emerged to solve this problem, each with a specific architectural philosophy. Understanding the trade-offs between client-side storage, server-side storage, and isomorphic bridging is critical for making the right choice.

🍪 Parsing vs. Managing: The Role of cookie-parser

Before you can manage a session, you often need to read the cookie. cookie-parser does not create sessions; it simply decrypts signed cookies and populates req.cookies or req.signedCookies. It is the foundational layer.

cookie-parser requires you to manually handle the logic of what the cookie contains. It is perfect for stateless auth patterns where you store a JWT directly in the cookie.

// cookie-parser: Manual JWT handling
const cookieParser = require('cookie-parser');
app.use(cookieParser('secret-key'));

app.get('/profile', (req, res) => {
  // You must manually verify and decode the token
  const token = req.signedCookies['auth_token'];
  if (!token) return res.status(401).send('Unauthorized');
  
  const user = verifyJwt(token);
  res.json(user);
});

cookie-session, express-session, and universal-cookie-express all rely on parsing cookies internally, but they abstract this away to provide a req.session object. You typically do not use cookie-parser alongside these unless you have mixed requirements (e.g., a session plus a separate tracking cookie).

// express-session: Abstracted parsing
const session = require('express-session');
app.use(session({ secret: 'secret-key', resave: false, saveUninitialized: true }));

app.get('/profile', (req, res) => {
  // Session is automatically parsed and attached to req.session
  if (!req.session.userId) return res.status(401).send('Unauthorized');
  res.json({ id: req.session.userId });
});

🗄️ Storage Architecture: Client-Side vs. Server-Side

The most significant architectural decision is where the session data lives. This dictates your scalability, security model, and infrastructure costs.

cookie-session stores the entire session object inside the cookie itself. The server only holds the secret key to verify integrity. This means the server is stateless regarding sessions.

// cookie-session: Data lives in the browser
const cookieSession = require('cookie-session');
app.use(cookieSession({
  name: 'session',
  keys: ['key1', 'key2'],
  maxAge: 24 * 60 * 60 * 1000 // 24 hours
}));

app.use((req, res, next) => {
  // Directly modifying the object updates the cookie header
  req.session.views = (req.session.views || 0) + 1;
  next();
});

express-session stores only a Session ID in the cookie. The actual data lives on the server (in memory by default, or a database).

// express-session: Data lives on the server
const session = require('express-session');
app.use(session({
  secret: 'secret-key',
  resave: false,
  saveUninitialized: true,
  store: new RedisStore({ client: redisClient }) // External store
}));

app.use((req, res, next) => {
  // Modifying this updates the database/store, not the cookie size
  req.session.views = (req.session.views || 0) + 1;
  next();
});

Trade-off: cookie-session limits you to ~4KB of data (browser cookie limit) and makes every request heavier. express-session allows unlimited data size but requires infrastructure (like Redis) to share sessions across multiple server instances.

🔄 Session Lifecycle and Invalidation

How you handle logging out or changing user permissions depends heavily on where the data is stored.

cookie-session cannot easily invalidate a session before it expires. Since the data is on the client, the server cannot "delete" it remotely. You must wait for the cookie to expire or overwrite it with empty data.

// cookie-session: Hard to revoke instantly
app.post('/logout', (req, res) => {
  // We can only clear the local object, hoping the client respects the clear
  req.session = null;
  res.send('Logged out (but cookie valid until expiry if intercepted)');
});

express-session allows immediate invalidation because the server holds the source of truth. Deleting the record in Redis instantly kills the session everywhere.

// express-session: Instant revocation
app.post('/logout', (req, res, next) => {
  req.session.destroy((err) => {
    if (err) return next(err);
    res.clearCookie('connect.sid'); // Remove the ID from client
    res.send('Session destroyed on server');
  });
});

universal-cookie-express follows the pattern of the underlying store it bridges, but its primary goal is ensuring the initial load matches between server and client.

// universal-cookie-express: Bridging context
import universalCookieExpress from 'universal-cookie-express';
app.use(universalCookieExpress(['accessToken']));

// Ensures req.universalCookies is populated for SSR
app.get('*', (req, res) => {
  const token = req.universalCookies.get('accessToken');
  // Render React app with this token available immediately
});

🌐 Isomorphic Rendering: The Universal Case

For React applications rendered on the server (SSR), accessing cookies during the initial render is tricky. The browser sends cookies to the server, but your React components usually expect to read them from document.cookie on the client.

universal-cookie-express solves this by extracting cookies from the Express request and placing them in a context that universal-cookie (the React companion) can read.

// universal-cookie-express: SSR Setup
import universalCookieExpress from 'universal-cookie-express';

// Tell the middleware which cookies to extract
app.use(universalCookieExpress(['userPreferences', 'theme']));

app.use((req, res) => {
  // These cookies are now available in the React context during renderToString
  const html = renderToString(<App />);
  res.send(html);
});

Neither cookie-session nor express-session provides this bridging out of the box for React component trees; they operate strictly on the req object. You would need manual wiring to pass req.session down into your React props.

// express-session: Manual SSR wiring
app.use((req, res) => {
  // Manually passing session to React props
  const html = renderToString(<App sessionData={req.session} />);
  res.send(html);
});

⚠️ Deprecation and Maintenance Status

It is vital to note the current maintenance status of these libraries.

universal-cookie-express is officially deprecated. The maintainers have moved functionality into the core universal-cookie package or recommend alternative approaches for newer versions of React/Next.js. Do not use this package in new projects. Instead, access cookies directly from the request headers in your server entry point and pass them as props or context to your application.

// Recommended approach instead of universal-cookie-express
import { Cookies } from 'universal-cookie';

app.get('*', (req, res) => {
  // Manually instantiate cookies from request headers
  const cookies = new Cookies(req.headers.cookie);
  const token = cookies.get('token');
  
  const html = renderToString(<App token={token} />);
  res.send(html);
});

The other three packages (cookie-parser, cookie-session, express-session) remain actively maintained and are safe for production use, though express-session is the de facto standard for serious applications.

📊 Summary of Technical Trade-offs

Feature	`cookie-parser`	`cookie-session`	`express-session`	`universal-cookie-express`
Primary Goal	Parse signed cookies	Client-side sessions	Server-side sessions	SSR Cookie Bridging
Data Location	N/A (Parser only)	Browser Cookie	Server Store (Redis/DB)	Context Propagation
Max Data Size	N/A	~4KB Limit	Unlimited	N/A
Revocation	Manual	Impossible (wait for expiry)	Instant (delete store key)	N/A
Infrastructure	None	None	Requires Store (for scaling)	None
Status	✅ Active	✅ Active	✅ Active	❌ Deprecated

💡 Architectural Recommendation

For most professional applications, express-session combined with a Redis store is the correct architectural choice. It provides the necessary security controls, allows for immediate session revocation (critical for logout and security patches), and supports horizontal scaling.

Use cookie-parser if you are implementing stateless authentication (like JWTs) and do not need a server-side session store.

Avoid cookie-session unless you are building a very simple tool where setting up a database is overkill and you accept the security limitations of client-side storage.

Finally, discard universal-cookie-express from your consideration for new builds; handle cookie extraction manually in your server-side rendering entry point to ensure long-term maintainability.

How to Choose: express-session vs cookie-parser vs cookie-session vs universal-cookie-express

express-session:
Choose express-session for production-grade applications requiring robust security, large session payloads, and immediate session invalidation capabilities. It is the correct choice when you need to integrate with external stores like Redis or MongoDB to support horizontal scaling across multiple server instances. Use this when security compliance and control over session lifecycle (touch, destroy, regenerate) are top priorities.
cookie-parser:
Choose cookie-parser when you need fine-grained control over individual cookies rather than a full session object. It is essential if you are manually managing authentication tokens (like JWTs) in cookies or need to verify signed cookies without tying your logic to a specific session store implementation. It is often used as a dependency for other middleware but works best as a standalone tool for simple read/write operations.
cookie-session:
Choose cookie-session for stateless architectures where you want to avoid setting up a database or Redis cluster for session storage. It is ideal for small-scale applications, microservices that cannot share a central store, or prototypes where speed of setup is critical. Avoid it if you need to store large amounts of data or require the ability to revoke a session immediately without waiting for expiration.
universal-cookie-express:

Popular Comparisons

express-session

cookie-parser

cookie-session

universal-cookie-express

README for express-session

express-session

Installation

This is a Node.js module available through the npm registry. Installation is done using the npm install command:

$ npm install express-session

API

var session = require('express-session')

session(options)

Create a session middleware with the given options.

Note Session data is not saved in the cookie itself, just the session ID. Session data is stored server-side.

Note Since version 1.5.0, the cookie-parser middleware no longer needs to be used for this module to work. This module now directly reads and writes cookies on req/res. Using cookie-parser may result in issues if the secret is not the same between this module and cookie-parser.

Warning The default server-side session storage, MemoryStore, is purposely not designed for a production environment. It will leak memory under most conditions, does not scale past a single process, and is meant for debugging and developing.

For a list of stores, see compatible session stores.

Options

express-session accepts these properties in the options object.

cookie

Settings object for the session ID cookie. The default value is { path: '/', httpOnly: true, secure: false, maxAge: null }.

In addition to providing a static object, you can also pass a callback function to dynamically generate the cookie options for each request. The callback receives the req object as its argument and should return an object containing the cookie settings.

var app = express()
app.use(session({
  secret: 'keyboard cat',
  resave: false,
  saveUninitialized: true,
  cookie: function(req) {
    var match = req.url.match(/^\/([^/]+)/);
    return {
      path: match ? '/' + match[1] : '/',
      httpOnly: true,
      secure: req.secure || false,
      maxAge: 60000
    }
  }
}))

The following are options that can be set in this object.

cookie.domain

Specifies the value for the Domain Set-Cookie attribute. By default, no domain is set, and most clients will consider the cookie to apply to only the current domain.

cookie.expires

Specifies the Date object to be the value for the Expires Set-Cookie attribute. By default, no expiration is set, and most clients will consider this a "non-persistent cookie" and will delete it on a condition like exiting a web browser application.

Note If both expires and maxAge are set in the options, then the last one defined in the object is what is used.

Note The expires option should not be set directly; instead only use the maxAge option.

cookie.httpOnly

Specifies the boolean value for the HttpOnly Set-Cookie attribute. When truthy, the HttpOnly attribute is set, otherwise it is not. By default, the HttpOnly attribute is set.

Note be careful when setting this to true, as compliant clients will not allow client-side JavaScript to see the cookie in document.cookie.

cookie.maxAge

Specifies the number (in milliseconds) to use when calculating the Expires Set-Cookie attribute. This is done by taking the current server time and adding maxAge milliseconds to the value to calculate an Expires datetime. By default, no maximum age is set.

Note If both expires and maxAge are set in the options, then the last one defined in the object is what is used.

cookie.partitioned

Specifies the boolean value for the Partitioned Set-Cookie attribute. When truthy, the Partitioned attribute is set, otherwise it is not. By default, the Partitioned attribute is not set.

Note This is an attribute that has not yet been fully standardized, and may change in the future. This also means many clients may ignore this attribute until they understand it.

More information about can be found in the proposal.

cookie.path

Specifies the value for the Path Set-Cookie. By default, this is set to '/', which is the root path of the domain.

cookie.priority

Specifies the string to be the value for the Priority Set-Cookie attribute.

'low' will set the Priority attribute to Low.
'medium' will set the Priority attribute to Medium, the default priority when not set.
'high' will set the Priority attribute to High.

More information about the different priority levels can be found in the specification.

Note This is an attribute that has not yet been fully standardized, and may change in the future. This also means many clients may ignore this attribute until they understand it.

cookie.sameSite

Specifies the boolean or string to be the value for the SameSite Set-Cookie attribute. By default, this is false.

true will set the SameSite attribute to Strict for strict same site enforcement.
false will not set the SameSite attribute.
'lax' will set the SameSite attribute to Lax for lax same site enforcement.
'none' will set the SameSite attribute to None for an explicit cross-site cookie.
'strict' will set the SameSite attribute to Strict for strict same site enforcement.
'auto' will set the SameSite attribute to None for secure connections and Lax for non-secure connections.

More information about the different enforcement levels can be found in the specification.

Note This is an attribute that has not yet been fully standardized, and may change in the future. This also means many clients may ignore this attribute until they understand it.

Note There is a draft spec that requires that the Secure attribute be set to true when the SameSite attribute has been set to 'none'. Some web browsers or other clients may be adopting this specification.

The cookie.sameSite option can also be set to the special value 'auto' to have this setting automatically match the determined security of the connection. When the connection is secure (HTTPS), the SameSite attribute will be set to None to enable cross-site usage. When the connection is not secure (HTTP), the SameSite attribute will be set to Lax for better security while maintaining functionality. This is useful when the Express "trust proxy" setting is properly setup to simplify development vs production configuration, particularly for SAML authentication scenarios.

cookie.secure

Specifies the boolean value for the Secure Set-Cookie attribute. When truthy, the Secure attribute is set, otherwise it is not. By default, the Secure attribute is not set.

Note be careful when setting this to true, as compliant clients will not send the cookie back to the server in the future if the browser does not have an HTTPS connection.

Please note that secure: true is a recommended option. However, it requires an https-enabled website, i.e., HTTPS is necessary for secure cookies. If secure is set, and you access your site over HTTP, the cookie will not be set. If you have your node.js behind a proxy and are using secure: true, you need to set "trust proxy" in express:

var app = express()
app.set('trust proxy', 1) // trust first proxy
app.use(session({
  secret: 'keyboard cat',
  resave: false,
  saveUninitialized: true,
  cookie: { secure: true }
}))

For using secure cookies in production, but allowing for testing in development, the following is an example of enabling this setup based on NODE_ENV in express:

var app = express()
var sess = {
  secret: 'keyboard cat',
  cookie: {}
}

if (app.get('env') === 'production') {
  app.set('trust proxy', 1) // trust first proxy
  sess.cookie.secure = true // serve secure cookies
}

app.use(session(sess))

The cookie.secure option can also be set to the special value 'auto' to have this setting automatically match the determined security of the connection. Be careful when using this setting if the site is available both as HTTP and HTTPS, as once the cookie is set on HTTPS, it will no longer be visible over HTTP. This is useful when the Express "trust proxy" setting is properly setup to simplify development vs production configuration.

genid

Function to call to generate a new session ID. Provide a function that returns a string that will be used as a session ID. The function is given req as the first argument if you want to use some value attached to req when generating the ID.

The default value is a function which uses the uid-safe library to generate IDs.

NOTE be careful to generate unique IDs so your sessions do not conflict.

app.use(session({
  genid: function(req) {
    return genuuid() // use UUIDs for session IDs
  },
  secret: 'keyboard cat'
}))

name

The name of the session ID cookie to set in the response (and read from in the request).

The default value is 'connect.sid'.

Note if you have multiple apps running on the same hostname (this is just the name, i.e. localhost or 127.0.0.1; different schemes and ports do not name a different hostname), then you need to separate the session cookies from each other. The simplest method is to simply set different names per app.

proxy

Trust the reverse proxy when setting secure cookies (via the "X-Forwarded-Proto" header).

The default value is undefined.

true The "X-Forwarded-Proto" header will be used.
false All headers are ignored and the connection is considered secure only if there is a direct TLS/SSL connection.
undefined Uses the "trust proxy" setting from express

resave

Forces the session to be saved back to the session store, even if the session was never modified during the request. Depending on your store this may be necessary, but it can also create race conditions where a client makes two parallel requests to your server and changes made to the session in one request may get overwritten when the other request ends, even if it made no changes (this behavior also depends on what store you're using).

The default value is true, but using the default has been deprecated, as the default will change in the future. Please research into this setting and choose what is appropriate to your use-case. Typically, you'll want false.

How do I know if this is necessary for my store? The best way to know is to check with your store if it implements the touch method. If it does, then you can safely set resave: false. If it does not implement the touch method and your store sets an expiration date on stored sessions, then you likely need resave: true.

rolling

Force the session identifier cookie to be set on every response. The expiration is reset to the original maxAge, resetting the expiration countdown.

The default value is false.

With this enabled, the session identifier cookie will expire in maxAge since the last response was sent instead of in maxAge since the session was last modified by the server.

This is typically used in conjunction with short, non-session-length maxAge values to provide a quick timeout of the session data with reduced potential of it occurring during on going server interactions.

Note When this option is set to true but the saveUninitialized option is set to false, the cookie will not be set on a response with an uninitialized session. This option only modifies the behavior when an existing session was loaded for the request.

saveUninitialized

Forces a session that is "uninitialized" to be saved to the store. A session is uninitialized when it is new but not modified. Choosing false is useful for implementing login sessions, reducing server storage usage, or complying with laws that require permission before setting a cookie. Choosing false will also help with race conditions where a client makes multiple parallel requests without a session.

The default value is true, but using the default has been deprecated, as the default will change in the future. Please research into this setting and choose what is appropriate to your use-case.

Note if you are using Session in conjunction with PassportJS, Passport will add an empty Passport object to the session for use after a user is authenticated, which will be treated as a modification to the session, causing it to be saved. This has been fixed in PassportJS 0.3.0

secret

Required option

This is the secret used to sign the session ID cookie. The secret can be any type of value that is supported by Node.js crypto.createHmac (like a string or a Buffer). This can be either a single secret, or an array of multiple secrets. If an array of secrets is provided, only the first element will be used to sign the session ID cookie, while all the elements will be considered when verifying the signature in requests. The secret itself should be not easily parsed by a human and would best be a random set of characters. A best practice may include:

The use of environment variables to store the secret, ensuring the secret itself does not exist in your repository.
Periodic updates of the secret, while ensuring the previous secret is in the array.

Using a secret that cannot be guessed will reduce the ability to hijack a session to only guessing the session ID (as determined by the genid option).

Changing the secret value will invalidate all existing sessions. In order to rotate the secret without invalidating sessions, provide an array of secrets, with the new secret as first element of the array, and including previous secrets as the later elements.

Note HMAC-256 is used to sign the session ID. For this reason, the secret should contain at least 32 bytes of entropy.

store

The session store instance, defaults to a new MemoryStore instance.

unset

Control the result of unsetting req.session (through delete, setting to null, etc.).

The default value is 'keep'.

'destroy' The session will be destroyed (deleted) when the response ends.
'keep' The session in the store will be kept, but modifications made during the request are ignored and not saved.

req.session

To store or access session data, simply use the request property req.session, which is (generally) serialized as JSON by the store, so nested objects are typically fine. For example below is a user-specific view counter:

// Use the session middleware
app.use(session({ secret: 'keyboard cat', cookie: { maxAge: 60000 }}))

// Access the session as req.session
app.get('/', function(req, res, next) {
  if (req.session.views) {
    req.session.views++
    res.setHeader('Content-Type', 'text/html')
    res.write('<p>views: ' + req.session.views + '</p>')
    res.write('<p>expires in: ' + (req.session.cookie.maxAge / 1000) + 's</p>')
    res.end()
  } else {
    req.session.views = 1
    res.end('welcome to the session demo. refresh!')
  }
})

Session.regenerate(callback)

To regenerate the session simply invoke the method. Once complete, a new SID and Session instance will be initialized at req.session and the callback will be invoked.

req.session.regenerate(function(err) {
  // will have a new session here
})

Session.destroy(callback)

Destroys the session and will unset the req.session property. Once complete, the callback will be invoked.

req.session.destroy(function(err) {
  // cannot access session here
})

Session.reload(callback)

Reloads the session data from the store and re-populates the req.session object. Once complete, the callback will be invoked.

req.session.reload(function(err) {
  // session updated
})

Session.save(callback)

Save the session back to the store, replacing the contents on the store with the contents in memory (though a store may do something else--consult the store's documentation for exact behavior).

This method is automatically called at the end of the HTTP response if the session data has been altered (though this behavior can be altered with various options in the middleware constructor). Because of this, typically this method does not need to be called.

There are some cases where it is useful to call this method, for example, redirects, long-lived requests or in WebSockets.

req.session.save(function(err) {
  // session saved
})

Session.touch()

Updates the .maxAge property. Typically this is not necessary to call, as the session middleware does this for you.

req.session.id

Each session has a unique ID associated with it. This property is an alias of req.sessionID and cannot be modified. It has been added to make the session ID accessible from the session object.

req.session.cookie

Each session has a unique cookie object accompany it. This allows you to alter the session cookie per visitor. For example we can set req.session.cookie.expires to false to enable the cookie to remain for only the duration of the user-agent.

Cookie.maxAge

Alternatively req.session.cookie.maxAge will return the time remaining in milliseconds, which we may also re-assign a new value to adjust the .expires property appropriately. The following are essentially equivalent

var hour = 3600000
req.session.cookie.expires = new Date(Date.now() + hour)
req.session.cookie.maxAge = hour

For example when maxAge is set to 60000 (one minute), and 30 seconds has elapsed it will return 30000 until the current request has completed, at which time req.session.touch() is called to reset req.session.cookie.maxAge to its original value.

req.session.cookie.maxAge // => 30000

Cookie.originalMaxAge

The req.session.cookie.originalMaxAge property returns the original maxAge (time-to-live), in milliseconds, of the session cookie.

req.sessionID

To get the ID of the loaded session, access the request property req.sessionID. This is simply a read-only value set when a session is loaded/created.

Session Store Implementation

Every session store must be an EventEmitter and implement specific methods. The following methods are the list of required, recommended, and optional.

Required methods are ones that this module will always call on the store.
Recommended methods are ones that this module will call on the store if available.
Optional methods are ones this module does not call at all, but helps present uniform stores to users.

For an example implementation view the connect-redis repo.

store.all(callback)

Optional

This optional method is used to get all sessions in the store as an array. The callback should be called as callback(error, sessions).

store.destroy(sid, callback)

Required

This required method is used to destroy/delete a session from the store given a session ID (sid). The callback should be called as callback(error) once the session is destroyed.

store.clear(callback)

Optional

This optional method is used to delete all sessions from the store. The callback should be called as callback(error) once the store is cleared.

store.length(callback)

Optional

This optional method is used to get the count of all sessions in the store. The callback should be called as callback(error, len).

store.get(sid, callback)

Required

This required method is used to get a session from the store given a session ID (sid). The callback should be called as callback(error, session).

The session argument should be a session if found, otherwise null or undefined if the session was not found (and there was no error). A special case is made when error.code === 'ENOENT' to act like callback(null, null).

store.set(sid, session, callback)

Required

This required method is used to upsert a session into the store given a session ID (sid) and session (session) object. The callback should be called as callback(error) once the session has been set in the store.

store.touch(sid, session, callback)

Recommended

This recommended method is used to "touch" a given session given a session ID (sid) and session (session) object. The callback should be called as callback(error) once the session has been touched.

This is primarily used when the store will automatically delete idle sessions and this method is used to signal to the store the given session is active, potentially resetting the idle timer.

Compatible Session Stores

The following modules implement a session store that is compatible with this module. Please make a PR to add additional modules :)

aerospike-session-store A session store using Aerospike.

better-sqlite3-session-store A session store based on better-sqlite3.

cassandra-store An Apache Cassandra-based session store.

cluster-store A wrapper for using in-process / embedded stores - such as SQLite (via knex), leveldb, files, or memory - with node cluster (desirable for Raspberry Pi 2 and other multi-core embedded devices).

connect-arango An ArangoDB-based session store.

connect-azuretables An Azure Table Storage-based session store.

connect-cloudant-store An IBM Cloudant-based session store.

connect-cosmosdb An Azure Cosmos DB-based session store.

connect-couchbase A couchbase-based session store.

connect-datacache An IBM Bluemix Data Cache-based session store.

@google-cloud/connect-datastore A Google Cloud Datastore-based session store.

connect-db2 An IBM DB2-based session store built using ibm_db module.

connect-dynamodb A DynamoDB-based session store.

@google-cloud/connect-firestore A Google Cloud Firestore-based session store.

connect-hazelcast Hazelcast session store for Connect and Express.

connect-loki A Loki.js-based session store.

connect-lowdb A lowdb-based session store.

connect-memcached A memcached-based session store.

connect-memjs A memcached-based session store using memjs as the memcached client.

connect-ml A MarkLogic Server-based session store.

connect-monetdb A MonetDB-based session store.

connect-mongo A MongoDB-based session store.

connect-mongodb-session Lightweight MongoDB-based session store built and maintained by MongoDB.

connect-mssql-v2 A Microsoft SQL Server-based session store based on connect-mssql.

connect-neo4j A Neo4j-based session store.

connect-ottoman A couchbase ottoman-based session store.

connect-pg-simple A PostgreSQL-based session store.

connect-redis A Redis-based session store.

connect-session-firebase A session store based on the Firebase Realtime Database

connect-session-knex A session store using Knex.js, which is a SQL query builder for PostgreSQL, MySQL, MariaDB, SQLite3, and Oracle.

connect-session-sequelize A session store using Sequelize.js, which is a Node.js / io.js ORM for PostgreSQL, MySQL, SQLite and MSSQL.

connect-sqlite3 A SQLite3 session store modeled after the TJ's connect-redis store.

connect-typeorm A TypeORM-based session store.

couchdb-expression A CouchDB-based session store.

dynamodb-store A DynamoDB-based session store.

dynamodb-store-v3 Implementation of a session store using DynamoDB backed by the AWS SDK for JavaScript v3.

express-etcd An etcd based session store.

express-mysql-session A session store using native MySQL via the node-mysql module.

express-nedb-session A NeDB-based session store.

express-oracle-session A session store using native oracle via the node-oracledb module.

express-session-cache-manager A store that implements cache-manager, which supports a variety of storage types.

express-session-etcd3 An etcd3 based session store.

express-session-level A LevelDB based session store.

express-session-rsdb Session store based on Rocket-Store: A very simple, super fast and yet powerful, flat file database.

express-sessions A session store supporting both MongoDB and Redis.

firestore-store A Firestore-based session store.

fortune-session A Fortune.js based session store. Supports all backends supported by Fortune (MongoDB, Redis, Postgres, NeDB).

hazelcast-store A Hazelcast-based session store built on the Hazelcast Node Client.

level-session-store A LevelDB-based session store.

lowdb-session-store A lowdb-based session store.

medea-session-store A Medea-based session store.

memorystore A memory session store made for production.

mssql-session-store A SQL Server-based session store.

nedb-session-store An alternate NeDB-based (either in-memory or file-persisted) session store.

@quixo3/prisma-session-store A session store for the Prisma Framework.

restsession Store sessions utilizing a RESTful API

sequelstore-connect A session store using Sequelize.js.

session-file-store A file system-based session store.

session-pouchdb-store Session store for PouchDB / CouchDB. Accepts embedded, custom, or remote PouchDB instance and realtime synchronization.

@cyclic.sh/session-store A DynamoDB-based session store for Cyclic.sh apps.

@databunker/session-store A Databunker-based encrypted session store.

sessionstore A session store that works with various databases.

tch-nedb-session A file system session store based on NeDB.

Examples

View counter

A simple example using express-session to store page views for a user.

var express = require('express')
var parseurl = require('parseurl')
var session = require('express-session')

var app = express()

app.use(session({
  secret: 'keyboard cat',
  resave: false,
  saveUninitialized: true
}))

app.use(function (req, res, next) {
  if (!req.session.views) {
    req.session.views = {}
  }

  // get the url pathname
  var pathname = parseurl(req).pathname

  // count the views
  req.session.views[pathname] = (req.session.views[pathname] || 0) + 1

  next()
})

app.get('/foo', function (req, res, next) {
  res.send('you viewed this page ' + req.session.views['/foo'] + ' times')
})

app.get('/bar', function (req, res, next) {
  res.send('you viewed this page ' + req.session.views['/bar'] + ' times')
})

app.listen(3000)

User login

A simple example using express-session to keep a user log in session.

var escapeHtml = require('escape-html')
var express = require('express')
var session = require('express-session')

var app = express()

app.use(session({
  secret: 'keyboard cat',
  resave: false,
  saveUninitialized: true
}))

// middleware to test if authenticated
function isAuthenticated (req, res, next) {
  if (req.session.user) next()
  else next('route')
}

app.get('/', isAuthenticated, function (req, res) {
  // this is only called when there is an authentication user due to isAuthenticated
  res.send('hello, ' + escapeHtml(req.session.user) + '!' +
    ' <a href="https://github.com/expressjs/session/blob/HEAD//logout">Logout</a>')
})

app.get('/', function (req, res) {
  res.send('<form action="/login" method="post">' +
    'Username: <input name="user"><br>' +
    'Password: <input name="pass" type="password"><br>' +
    '<input type="submit" text="Login"></form>')
})

app.post('/login', express.urlencoded({ extended: false }), function (req, res) {
  // login logic to validate req.body.user and req.body.pass
  // would be implemented here. for this example any combo works

  // regenerate the session, which is good practice to help
  // guard against forms of session fixation
  req.session.regenerate(function (err) {
    if (err) next(err)

    // store user information in session, typically a user id
    req.session.user = req.body.user

    // save the session before redirection to ensure page
    // load does not happen before session is saved
    req.session.save(function (err) {
      if (err) return next(err)
      res.redirect('/')
    })
  })
})

app.get('/logout', function (req, res, next) {
  // logout logic

  // clear the user from the session object and save.
  // this will ensure that re-using the old session id
  // does not have a logged in user
  req.session.user = null
  req.session.save(function (err) {
    if (err) next(err)

    // regenerate the session, which is good practice to help
    // guard against forms of session fixation
    req.session.regenerate(function (err) {
      if (err) next(err)
      res.redirect('/')
    })
  })
})

app.listen(3000)

Debugging

This module uses the debug module internally to log information about session operations.

To see all the internal logs, set the DEBUG environment variable to express-session when launching your app (npm start, in this example):

$ DEBUG=express-session npm start

On Windows, use the corresponding command;

> set DEBUG=express-session & npm start

License

MIT

Managing HTTP Cookies and Sessions in Express Applications

Npm Package Weekly Downloads Trend

Github Stars Ranking

Stat Detail

Managing HTTP Cookies and Sessions in Express Applications

🍪 Parsing vs. Managing: The Role of cookie-parser

🗄️ Storage Architecture: Client-Side vs. Server-Side

🔄 Session Lifecycle and Invalidation

🌐 Isomorphic Rendering: The Universal Case

⚠️ Deprecation and Maintenance Status

📊 Summary of Technical Trade-offs

💡 Architectural Recommendation

How to Choose: express-session vs cookie-parser vs cookie-session vs universal-cookie-express

Popular Comparisons

Similar Npm Packages to express-session

Similar Npm Packages to cookie-parser

Similar Npm Packages to cookie-session

Similar Npm Packages to universal-cookie-express

README for express-session

express-session

Installation

API

session(options)

Options

cookie

cookie.domain

cookie.expires

cookie.httpOnly

cookie.maxAge

cookie.partitioned

cookie.path

cookie.priority

cookie.sameSite

cookie.secure

genid

name

proxy

resave

rolling

saveUninitialized

secret

store

unset

req.session

Session.regenerate(callback)

Session.destroy(callback)

Session.reload(callback)

Session.save(callback)

Session.touch()

req.session.id

req.session.cookie

Cookie.maxAge

Cookie.originalMaxAge

req.sessionID

Session Store Implementation

store.all(callback)

store.destroy(sid, callback)

store.clear(callback)

store.length(callback)

store.get(sid, callback)

store.set(sid, session, callback)

store.touch(sid, session, callback)

Compatible Session Stores

Examples

View counter

User login

Debugging

License