middleware session

Instalación

Este es un módulo de Node.js disponible a través del registro npm. La instalación se hace usando el comando npm install:

npm install express-session

API

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

session(options)

Crea un middleware de sesión con las options dadas.

Nota Los datos de la sesión no se guardan en la cookie misma, solo el ID de sesión. Los datos de la sesión se almacenan en el servidor.

Nota Desde la versión 1.5.0, el middleware cookie-parser ya no necesita usarse para que este módulo funcione. Este módulo ahora lee y escribe directamente cookies en req/res. Usar cookie-parser puede resultar en problemas si el secret no es el mismo entre este módulo y cookie-parser.

Advertencia El almacenamiento de sesión por defecto del lado del servidor, MemoryStore, está intencionadamente diseñado para no usarse en un entorno de producción. Fugará memoria en la mayoría de las condiciones, no escala más allá de un único proceso, y está pensado para depuración y desarrollo.

Para ver una lista de stores, consulta session stores compatibles.

Opciones

express-session acepta estas propiedades en el objeto options.

Objeto de configuración para la cookie del ID de sesión. El valor por defecto es { path: '/', httpOnly: true, secure: false, maxAge: null }.

Además de proporcionar un objeto estático, también puedes pasar una función callback para generar dinámicamente las opciones de cookie para cada petición. El callback recibe el objeto req como argumento y debe devolver un objeto con la configuración de la cookie.

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,
      };
    },
  })
);

Las siguientes son opciones que se pueden establecer en este objeto.

cookie.domain

Especifica el valor para el atributo Domain de Set-Cookie. Por defecto, no se establece ningún dominio, y la mayoría de los clientes considerarán que la cookie aplica solo al dominio actual.

cookie.expires

Especifica el objeto Date como valor para el atributo Expires de Set-Cookie. Por defecto, no se establece ninguna expiración, y la mayoría de los clientes considerarán esto como una "cookie no persistente" y la borrarán bajo una condición como salir de un navegador web.

Nota Si tanto expires como maxAge se establecen en las opciones, el último definido en el objeto es el que se usa.

Nota La opción expires no debe establecerse directamente; en su lugar usa solo la opción maxAge.

cookie.httpOnly

Especifica el valor boolean para el atributo HttpOnly de Set-Cookie. Cuando es verdadero, el atributo HttpOnly se establece, en caso contrario no. Por defecto, el atributo HttpOnly se establece.

Nota ten cuidado al establecer esto en true, ya que los clientes compatibles no permitirán que el JavaScript del lado del cliente vea la cookie en document.cookie.

cookie.maxAge

Especifica el number (en milisegundos) a usar al calcular el atributo Expires de Set-Cookie. Esto se hace tomando el tiempo actual del servidor y añadiendo maxAge milisegundos al valor para calcular una fecha Expires. Por defecto, no se establece una edad máxima.

Nota Si tanto expires como maxAge se establecen en las opciones, el último definido en el objeto es el que se usa.

cookie.partitioned

Especifica el valor boolean para el atributo Partitioned de Set-Cookie. Cuando es verdadero, el atributo Partitioned se establece, en caso contrario no. Por defecto, el atributo Partitioned no se establece.

Nota Este es un atributo que aún no se ha estandarizado por completo, y puede cambiar en el futuro. Esto también significa que muchos clientes pueden ignorar este atributo hasta que lo entiendan.

Más información se puede encontrar en la propuesta.

cookie.path

Especifica el valor para el Path de Set-Cookie. Por defecto, se establece en '/', que es la ruta raíz del dominio.

cookie.priority

Especifica el string como valor para el atributo Priority de Set-Cookie.

'low' establecerá el atributo Priority en Low.
'medium' establecerá el atributo Priority en Medium, la prioridad por defecto cuando no se establece.
'high' establecerá el atributo Priority en High.

Más información sobre los diferentes niveles de prioridad se puede encontrar en la especificación.

cookie.sameSite

Especifica el boolean o string como valor para el atributo SameSite de Set-Cookie. Por defecto, es false.

true establecerá el atributo SameSite en Strict para una aplicación estricta del mismo sitio.
false no establecerá el atributo SameSite.
'lax' establecerá el atributo SameSite en Lax para una aplicación lax del mismo sitio.
'none' establecerá el atributo SameSite en None para una cookie explícitamente cross-site.
'strict' establecerá el atributo SameSite en Strict para una aplicación estricta del mismo sitio.
'auto' establecerá el atributo SameSite en None para conexiones seguras y Lax para conexiones no seguras.

Más información sobre los diferentes niveles de aplicación se puede encontrar en la especificación.

Nota Hay un borrador de especificación que requiere que el atributo Secure se establezca en true cuando el atributo SameSite se ha establecido en 'none'. Algunos navegadores web u otros clientes pueden estar adoptando esta especificación.

La opción cookie.sameSite también se puede establecer en el valor especial 'auto' para que esta configuración coincida automáticamente con la seguridad determinada de la conexión. Cuando la conexión es segura (HTTPS), el atributo SameSite se establecerá en None para habilitar el uso cross-site. Cuando la conexión no es segura (HTTP), el atributo SameSite se establecerá en Lax para mejor seguridad manteniendo la funcionalidad. Esto es útil cuando la configuración "trust proxy" de Express está correctamente configurada para simplificar la configuración de desarrollo vs producción, particularmente para escenarios de autenticación SAML.

cookie.secure

Especifica el valor boolean para el atributo Secure de Set-Cookie. Cuando es verdadero, el atributo Secure se establece, en caso contrario no. Por defecto, el atributo Secure no se establece.

Nota ten cuidado al establecer esto en true, ya que los clientes compatibles no enviarán la cookie de vuelta al servidor en el futuro si el navegador no tiene una conexión HTTPS.

Ten en cuenta que secure: true es una opción recomendada. Sin embargo, requiere un sitio habilitado para https, es decir, HTTPS es necesario para cookies seguras. Si secure está establecido, y accedes a tu sitio por HTTP, la cookie no se establecerá. Si tienes tu node.js detrás de un proxy y estás usando secure: true, necesitas establecer "trust proxy" en 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 },
  })
);

Para usar cookies seguras en producción, pero permitir testing en desarrollo, el siguiente es un ejemplo de cómo habilitar esta configuración basándose en NODE_ENV en 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));

La opción cookie.secure también se puede establecer en el valor especial 'auto' para que esta configuración coincida automáticamente con la seguridad determinada de la conexión. Ten cuidado al usar esta configuración si el sitio está disponible tanto por HTTP como HTTPS, ya que una vez que la cookie se establece por HTTPS, ya no será visible por HTTP. Esto es útil cuando la configuración "trust proxy" de Express está correctamente configurada para simplificar la configuración de desarrollo vs producción.

genid

Función a llamar para generar un nuevo ID de sesión. Proporciona una función que devuelva una cadena que se usará como ID de sesión. La función recibe req como primer argumento si quieres usar algún valor adjunto a req al generar el ID.

El valor por defecto es una función que usa la librería uid-safe para generar IDs.

NOTA ten cuidado de generar IDs únicos para que tus sesiones no entren en conflicto.

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

name

El nombre de la cookie del ID de sesión a establecer en la respuesta (y a leer de la petición).

El valor por defecto es 'connect.sid'.

Nota si tienes múltiples apps ejecutándose en el mismo hostname (esto es solo el nombre, es decir localhost o 127.0.0.1; diferentes esquemas y puertos no constituyen un hostname diferente), entonces necesitas separar las cookies de sesión entre ellas. El método más simple es simplemente establecer diferentes names por app.

proxy

Confiar en el reverse proxy al establecer cookies seguras (a través de la cabecera "X-Forwarded-Proto").

El valor por defecto es undefined.

true Se usará la cabecera "X-Forwarded-Proto".
false Todas las cabeceras se ignoran y la conexión se considera segura solo si hay una conexión directa TLS/SSL.
undefined Usa la configuración "trust proxy" de express

resave

Fuerza a que la sesión se guarde de vuelta en el session store, incluso si la sesión nunca fue modificada durante la petición. Dependiendo de tu store esto puede ser necesario, pero también puede crear condiciones de carrera donde un cliente hace dos peticiones paralelas a tu servidor y los cambios hechos a la sesión en una petición pueden sobrescribirse cuando la otra petición termina, incluso si no hizo cambios (este comportamiento también depende de qué store estés usando).

El valor por defecto es true, pero usar el valor por defecto ha quedado obsoleto, ya que el valor por defecto cambiará en el futuro. Investiga sobre esta configuración y elige lo que sea apropiado para tu caso de uso. Típicamente, querrás false.

¿Cómo sé si esto es necesario para mi store? La mejor forma de saberlo es comprobar con tu store si implementa el método touch. Si lo hace, entonces puedes establecer resave: false de forma segura. Si no implementa el método touch y tu store establece una fecha de expiración en las sesiones almacenadas, entonces probablemente necesites resave: true.

rolling

Fuerza a que la cookie del identificador de sesión se establezca en cada respuesta. La expiración se reinicia al maxAge original, reiniciando la cuenta regresiva de expiración.

El valor por defecto es false.

Con esto habilitado, la cookie del identificador de sesión expirará en maxAge desde que se envió la última respuesta en lugar de en maxAge desde que la sesión fue modificada por última vez por el servidor.

Esto se usa típicamente junto con valores de maxAge cortos, de duración no de sesión, para proporcionar un timeout rápido de los datos de sesión con menor potencial de que ocurra durante interacciones continuas del servidor.

Nota Cuando esta opción se establece en true pero la opción saveUninitialized está establecida en false, la cookie no se establecerá en una respuesta con una sesión no inicializada. Esta opción solo modifica el comportamiento cuando una sesión existente fue cargada para la petición.

saveUninitialized

Fuerza a que una sesión "no inicializada" se guarde en el store. Una sesión está no inicializada cuando es nueva pero no modificada. Elegir false es útil para implementar sesiones de login, reducir el uso de almacenamiento del servidor, o cumplir con leyes que requieren permiso antes de establecer una cookie. Elegir false también ayudará con condiciones de carrera donde un cliente hace múltiples peticiones paralelas sin una sesión.

Nota si estás usando Session junto con PassportJS, Passport añadirá un objeto Passport vacío a la sesión para usar después de que un usuario sea autenticado, lo cual será tratado como una modificación a la sesión, causando que se guarde. Esto se ha corregido en PassportJS 0.3.0

secret

Required option

Este es el secreto usado para firmar la cookie del ID de sesión. El secreto puede ser cualquier tipo de valor soportado por crypto.createHmac de Node.js (como una cadena o un Buffer). Puede ser un único secreto, o un array de múltiples secretos. Si se proporciona un array de secretos, solo el primer elemento se usará para firmar la cookie del ID de sesión, mientras que todos los elementos se considerarán al verificar la firma en las peticiones. El secreto mismo no debería ser fácilmente analizable por un humano y lo mejor sería un conjunto aleatorio de caracteres. Una buena práctica puede incluir:

El uso de variables de entorno para almacenar el secreto, asegurando que el secreto mismo no exista en tu repositorio.
Actualizaciones periódicas del secreto, asegurando que el secreto anterior esté en el array.

Usar un secreto que no pueda adivinarse reducirá la capacidad de secuestrar una sesión a solo adivinar el ID de sesión (según lo determine la opción genid).

Cambiar el valor del secreto invalidará todas las sesiones existentes. Para rotar el secreto sin invalidar sesiones, proporciona un array de secretos, con el nuevo secreto como primer elemento del array, e incluyendo los secretos anteriores como los elementos posteriores.

Nota HMAC-256 se usa para firmar el ID de sesión. Por esta razón, el secreto debería contener al menos 32 bytes de entropía.

store

La instancia del session store, por defecto es una nueva instancia de MemoryStore.

unset

Controla el resultado de desestablecer req.session (a través de delete, estableciendo en null, etc.).

El valor por defecto es 'keep'.

'destroy' La sesión será destruida (eliminada) cuando la respuesta termine.
'keep' La sesión en el store se mantendrá, pero las modificaciones hechas durante la petición se ignoran y no se guardan.

req.session

Para almacenar o acceder a los datos de sesión, simplemente usa la propiedad de petición req.session, que (generalmente) se serializa como JSON por el store, así que los objetos anidados normalmente funcionan bien. Por ejemplo, a continuación hay un contador de vistas específico del usuario:

// 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)

Para regenerar la sesión simplemente invoca el método. Una vez completo, un nuevo SID e instancia de Session se inicializarán en req.session y el callback será invocado.

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

Session.destroy(callback)

Destruye la sesión y desestablecerá la propiedad req.session. Una vez completo, el callback será invocado.

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

Session.reload(callback)

Recarga los datos de sesión desde el store y repuebla el objeto req.session. Una vez completo, el callback será invocado.

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

Session.save(callback)

Guarda la sesión de vuelta en el store, reemplazando los contenidos del store con los contenidos en memoria (aunque un store puede hacer algo distinto—consulta la documentación del store para el comportamiento exacto).

Este método se llama automáticamente al final de la respuesta HTTP si los datos de sesión han sido alterados (aunque este comportamiento puede modificarse con varias opciones en el constructor del middleware). Por esto, típicamente este método no necesita ser llamado.

Hay algunos casos en los que es útil llamar a este método, por ejemplo, redirecciones, peticiones de larga duración o en WebSockets.

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

Session.touch()

Actualiza la propiedad .maxAge. Típicamente esto no es necesario llamarlo, ya que el middleware de sesión lo hace por ti.

req.session.id

Cada sesión tiene un ID único asociado. Esta propiedad es un alias de req.sessionID y no puede modificarse. Se ha añadido para hacer accesible el ID de sesión desde el objeto session.

req.session.cookie

Cada sesión tiene un objeto cookie único que la acompaña. Esto te permite alterar la cookie de sesión por visitante. Por ejemplo podemos establecer req.session.cookie.expires en false para que la cookie solo dure lo que dure el user-agent.

Cookie.maxAge

Alternativamente req.session.cookie.maxAge devolverá el tiempo restante en milisegundos, al cual también podemos reasignar un nuevo valor para ajustar la propiedad .expires apropiadamente. Los siguientes son esencialmente equivalentes

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

Por ejemplo cuando maxAge se establece en 60000 (un minuto), y han transcurrido 30 segundos devolverá 30000 hasta que la petición actual haya completado, en cuyo momento req.session.touch() se llama para reiniciar req.session.cookie.maxAge a su valor original.

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

Cookie.originalMaxAge

La propiedad req.session.cookie.originalMaxAge devuelve el maxAge original (tiempo de vida), en milisegundos, de la cookie de sesión.

req.sessionID

Para obtener el ID de la sesión cargada, accede a la propiedad de petición req.sessionID. Esto es simplemente un valor de solo lectura establecido cuando una sesión se carga/crea.

Implementación de Session Store

Cada session store debe ser un EventEmitter e implementar métodos específicos. Los siguientes métodos son la lista de requeridos, recomendados, y opcionales.

Los métodos requeridos son aquellos que este módulo siempre llamará en el store.
Los métodos recomendados son aquellos que este módulo llamará en el store si están disponibles.
Los métodos opcionales son aquellos que este módulo no llama en absoluto, pero ayuda a presentar stores uniformes a los usuarios.

Para ver un ejemplo de implementación consulta el repo de connect-redis.

store.all(callback)

Optional

Este método opcional se usa para obtener todas las sesiones del store como un array. El callback debe llamarse como callback(error, sessions).

store.destroy(sid, callback)

Required

Este método requerido se usa para destruir/eliminar una sesión del store dado un ID de sesión (sid). El callback debe llamarse como callback(error) una vez que la sesión se haya destruido.

store.clear(callback)

Optional

Este método opcional se usa para eliminar todas las sesiones del store. El callback debe llamarse como callback(error) una vez que el store se haya limpiado.

store.length(callback)

Optional

Este método opcional se usa para obtener el conteo de todas las sesiones en el store. El callback debe llamarse como callback(error, len).

store.get(sid, callback)

Required

Este método requerido se usa para obtener una sesión del store dado un ID de sesión (sid). El callback debe llamarse como callback(error, session).

El argumento session debe ser una sesión si se encuentra, en caso contrario null o undefined si la sesión no se encontró (y no hubo error). Un caso especial se hace cuando error.code === 'ENOENT' para actuar como callback(null, null).

store.set(sid, session, callback)

Required

Este método requerido se usa para hacer un upsert de una sesión en el store dado un ID de sesión (sid) y un objeto de sesión (session). El callback debe llamarse como callback(error) una vez que la sesión se haya establecido en el store.

store.touch(sid, session, callback)

Recommended

Este método recomendado se usa para "tocar" una sesión dada un ID de sesión (sid) y un objeto de sesión (session). El callback debe llamarse como callback(error) una vez que la sesión haya sido tocada.

Esto se usa principalmente cuando el store eliminará automáticamente sesiones inactivas y este método se usa para señalar al store que la sesión dada está activa, potencialmente reiniciando el temporizador de inactividad.

Session Stores compatibles

Los siguientes módulos implementan un session store que es compatible con este módulo. Haz un PR para añadir módulos adicionales :)

![★][aerospike-session-store-image] aerospike-session-store Un session store que usa Aerospike.

![★][better-sqlite3-session-store-image] better-sqlite3-session-store Un session store basado en better-sqlite3.

![★][cassandra-store-image] cassandra-store Un session store basado en Apache Cassandra.

![★][cluster-store-image] cluster-store Un wrapper para usar stores en proceso / embebidos - como SQLite (vía knex), leveldb, archivos, o memoria - con node cluster (deseable para Raspberry Pi 2 y otros dispositivos embebidos multi-core).

![★][connect-arango-image] connect-arango Un session store basado en ArangoDB.

![★][connect-azuretables-image] connect-azuretables Un session store basado en Azure Table Storage.

![★][connect-cloudant-store-image] connect-cloudant-store Un session store basado en IBM Cloudant.

![★][connect-cosmosdb-image] connect-cosmosdb Un session store basado en Azure Cosmos DB.

![★][connect-couchbase-image] connect-couchbase Un session store basado en couchbase.

![★][connect-datacache-image] connect-datacache Un session store basado en IBM Bluemix Data Cache.

![★][@google-cloud/connect-datastore-image] @google-cloud/connect-datastore Un session store basado en Google Cloud Datastore.

![★][connect-db2-image] connect-db2 Un session store basado en IBM DB2 construido con el módulo ibm_db.

![★][connect-dynamodb-image] connect-dynamodb Un session store basado en DynamoDB.

![★][@google-cloud/connect-firestore-image] @google-cloud/connect-firestore Un session store basado en Google Cloud Firestore.

![★][connect-hazelcast-image] connect-hazelcast Session store de Hazelcast para Connect y Express.

![★][connect-loki-image] connect-loki Un session store basado en Loki.js.

![★][connect-lowdb-image] connect-lowdb Un session store basado en lowdb.

![★][connect-memcached-image] connect-memcached Un session store basado en memcached.

![★][connect-memjs-image] connect-memjs Un session store basado en memcached que usa memjs como cliente de memcached.

![★][connect-ml-image] connect-ml Un session store basado en MarkLogic Server.

![★][connect-monetdb-image] connect-monetdb Un session store basado en MonetDB.

![★][connect-mongo-image] connect-mongo Un session store basado en MongoDB.

![★][connect-mongodb-session-image] connect-mongodb-session Session store ligero basado en MongoDB construido y mantenido por MongoDB.

![★][connect-mssql-v2-image] connect-mssql-v2 Un session store basado en Microsoft SQL Server basado en connect-mssql.

![★][connect-neo4j-image] connect-neo4j Un session store basado en Neo4j.

![★][connect-ottoman-image] connect-ottoman Un session store basado en couchbase ottoman.

![★][connect-pg-simple-image] connect-pg-simple Un session store basado en PostgreSQL.

![★][connect-redis-image] connect-redis Un session store basado en Redis.

![★][connect-session-firebase-image] connect-session-firebase Un session store basado en Firebase Realtime Database

![★][connect-session-knex-image] connect-session-knex Un session store que usa Knex.js, que es un constructor de consultas SQL para PostgreSQL, MySQL, MariaDB, SQLite3, y Oracle.

![★][connect-session-sequelize-image] connect-session-sequelize Un session store que usa Sequelize.js, que es un ORM de Node.js / io.js para PostgreSQL, MySQL, SQLite y MSSQL.

![★][connect-sqlite3-image] connect-sqlite3 Un session store de SQLite3 modelado a partir del store connect-redis de TJ.

![★][connect-typeorm-image] connect-typeorm Un session store basado en TypeORM.

![★][couchdb-expression-image] couchdb-expression Un session store basado en CouchDB.

![★][dynamodb-store-image] dynamodb-store Un session store basado en DynamoDB.

![★][express-etcd-image] express-etcd Un session store basado en etcd.

![★][express-mysql-session-image] express-mysql-session Un session store que usa MySQL nativo a través del módulo node-mysql.

![★][express-nedb-session-image] express-nedb-session Un session store basado en NeDB.

![★][express-oracle-session-image] express-oracle-session Un session store que usa oracle nativo a través del módulo node-oracledb.

![★][express-session-cache-manager-image] express-session-cache-manager Un store que implementa cache-manager, que soporta una variedad de tipos de almacenamiento.

![★][express-session-etcd3-image] express-session-etcd3 Un session store basado en etcd3.

![★][express-session-level-image] express-session-level Un session store basado en LevelDB.

![★][express-session-rsdb-image] express-session-rsdb Session store basado en Rocket-Store: Una base de datos de archivos planos muy simple, súper rápida y potente.

![★][express-sessions-image] express-sessions Un session store que soporta tanto MongoDB como Redis.

![★][firestore-store-image] firestore-store Un session store basado en Firestore.

![★][fortune-session-image] fortune-session Un session store basado en Fortune.js. Soporta todos los backends soportados por Fortune (MongoDB, Redis, Postgres, NeDB).

![★][hazelcast-store-image] hazelcast-store Un session store basado en Hazelcast construido sobre el Hazelcast Node Client.

![★][level-session-store-image] level-session-store Un session store basado en LevelDB.

![★][lowdb-session-store-image] lowdb-session-store Un session store basado en lowdb.

![★][medea-session-store-image] medea-session-store Un session store basado en Medea.

![★][memorystore-image] memorystore Un session store en memoria hecho para producción.

![★][mssql-session-store-image] mssql-session-store Un session store basado en SQL Server.

![★][nedb-session-store-image] nedb-session-store Un session store alternativo basado en NeDB (ya sea en memoria o persistido en archivo).

![★][@quixo3/prisma-session-store-image] @quixo3/prisma-session-store Un session store para el Prisma Framework.

![★][restsession-image] restsession Almacena sesiones utilizando una API RESTful

![★][sequelstore-connect-image] sequelstore-connect Un session store que usa Sequelize.js.

![★][session-file-store-image] session-file-store Un session store basado en el sistema de archivos.

![★][session-pouchdb-store-image] session-pouchdb-store Session store para PouchDB / CouchDB. Acepta instancias PouchDB embebidas, personalizadas o remotas y sincronización en tiempo real.

![★][@databunker/session-store-image] @databunker/session-store Un session store encriptado basado en Databunker.

![★][sessionstore-image] sessionstore Un session store que funciona con varias bases de datos.

![★][tch-nedb-session-image] tch-nedb-session Un session store del sistema de archivos basado en NeDB.

Ejemplos

Contador de visitas

Un ejemplo simple usando express-session para almacenar las vistas de página de un usuario.

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);

Un ejemplo simple usando express-session para mantener una sesión de login de usuario.

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="/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);

Depuración

Este módulo usa el módulo debug internamente para registrar información sobre las operaciones de sesión.

Para ver todos los logs internos, establece la variable de entorno DEBUG en express-session al iniciar tu app (npm start, en este ejemplo):

$ DEBUG=express-session npm start

En Windows, usa el comando correspondiente;

> set DEBUG=express-session & npm start

Licencia

MIT