Security News
ESLint is Now Language-Agnostic: Linting JSON, Markdown, and Beyond
ESLint has added JSON and Markdown linting support with new officially-supported plugins, expanding its versatility beyond JavaScript.
express-session
Advanced tools
The express-session npm package is a middleware for Express applications that enables server-side session management. It allows you to store and access user data as they interact with your web application. The package creates a session ID for each client and uses it to store data across multiple HTTP requests.
Session Initialization
This code initializes the express-session middleware with a secret to sign the session ID cookie, and configuration options such as 'resave', 'saveUninitialized', and 'cookie' settings.
const express = require('express');
const session = require('express-session');
const app = express();
app.use(session({
secret: 'keyboard cat',
resave: false,
saveUninitialized: true,
cookie: { secure: true }
}));
Storing Session Data
This code demonstrates how to store data in the session object. The value 'This is saved in session' is stored under the key 'myValue' in the session.
app.use(session({ /* ... */ }));
app.get('/save', function(req, res) {
// Save a value to the session
req.session.myValue = 'This is saved in session';
res.send('Session value stored.');
});
Retrieving Session Data
This code shows how to retrieve data from the session. It accesses the value stored under the key 'myValue' and sends it in the HTTP response.
app.get('/retrieve', function(req, res) {
// Retrieve a value from the session
const myValue = req.session.myValue;
res.send(`Session value: ${myValue}`);
});
Destroying a Session
This code provides an example of how to destroy a session, effectively logging out the user. It handles any errors that might occur during the destruction process.
app.get('/logout', function(req, res) {
// Destroy the session
req.session.destroy(function(err) {
if(err) {
return res.send('Error destroying session');
}
res.send('Session destroyed');
});
});
The cookie-session package is similar to express-session but stores the session data directly in a cookie on the client-side, rather than on the server. This can be simpler and more scalable for some applications, but it is less secure and has limitations on the amount of data you can store.
Connect-redis is a Redis session store for the express-session package. It requires express-session to be installed and configured, but it uses Redis to store session data, which can be more performant and scalable for applications with a high number of sessions.
Connect-mongo is a MongoDB session store for the express-session package. Similar to connect-redis, it leverages MongoDB to store session data, providing a scalable and performant solution for managing sessions in Express applications.
$ npm install express-session
var session = require('express-session')
Create a session middleware with the given options
.
Note Session data is not saved in the cookie itself, just the session ID. Session hdata is stored server-side.
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 it meant for debugging and
developing.
For a list of stores, see compatible session stores.
express-session
accepts these properties in the options object.
Settings for the session ID cookie. See the "Cookie options" section below for more information on the different values.
The default value is { path: '/', httpOnly: true, secure: false, maxAge: null }
.
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 uid2
library to generate IDs.
NOTE be careful you 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'
}))
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 host (hostname + port),
then you need to separate the session cookies from each other. The simplest
method is to simply set different name
s per app.
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
Use the "trust proxy" setting from expressForces 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 has 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
.h
Force a cookie to be set on every response. This resets the expiration date.
The default value is false
.
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. Choose 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.
Required option
This is the secret used to sign the session ID cookie.
The session store instance, defaults to a new MemoryStore
instance.
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.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
.
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))
By default cookie.maxAge
is null
, meaning no "expires" parameter is set
so the cookie becomes a browser-session cookie. When the user closes the
browser the cookie (and session) will be removed.
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:
app.use(session({ secret: 'keyboard cat', cookie: { maxAge: 60000 }}))
app.use(function(req, res, next) {
var sess = req.session
if (sess.views) {
sess.views++
res.setHeader('Content-Type', 'text/html')
res.write('<p>views: ' + sess.views + '</p>')
res.write('<p>expires in: ' + (sess.cookie.maxAge / 1000) + 's</p>')
res.end()
} else {
sess.views = 1
res.end('welcome to the session demo. refresh!')
}
})
To regenerate the session simply invoke the method, once complete
a new SID and Session
instance will be initialized at req.session
.
req.session.regenerate(function(err) {
// will have a new session here
})
Destroys the session, removing req.session
, will be re-generated next request.
req.session.destroy(function(err) {
// cannot access session here
})
Reloads the session data.
req.session.reload(function(err) {
// session updated
})
req.session.save(function(err) {
// session saved
})
Updates the .maxAge
property. Typically this is
not necessary to call, as the session middleware does this for you.
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.
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.maxAge
to its original value.
req.session.cookie.maxAge // => 30000
Every session store must be an EventEmitter
and implement the following
methods:
.get(sid, callback)
.set(sid, session, callback)
.destroy(sid, callback)
Recommended methods include, but are not limited to:
.touch(sid, session, callback)
.length(callback)
.clear(callback)
For an example implementation view the connect-redis repo.
The following modules implement a session store that is compatible with this module. Please make a PR to add additional modules :)
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) {
var views = req.session.views
if (!views) {
views = req.session.views = {}
}
// get the url pathname
var pathname = parseurl(req).pathname
// count the views
views[pathname] = (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')
})
FAQs
Simple session middleware for Express
The npm package express-session receives a total of 1,457,290 weekly downloads. As such, express-session popularity was classified as popular.
We found that express-session demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
ESLint has added JSON and Markdown linting support with new officially-supported plugins, expanding its versatility beyond JavaScript.
Security News
Members Hub is conducting large-scale campaigns to artificially boost Discord server metrics, undermining community trust and platform integrity.
Security News
NIST has failed to meet its self-imposed deadline of clearing the NVD's backlog by the end of the fiscal year. Meanwhile, CVE's awaiting analysis have increased by 33% since June.