[RomainLanz]

Hey! 👋

Problem

Requests from one browser can overlap. A logout, a regenerate() or a SessionCollection.destroy() can occur while another request runs. The session id is a UUID in a signed cookie, so a client cannot forge it. But the overlap could bring an ended session back:

request A (slow)              request B (logout)
read session S
                              destroy S
write S  → before: S exists again with the data A read
           now:    the write does nothing, S stays ended

1. The redis, database, file and dynamodb stores wrote back a session that another request destroyed.
2. When the cookie named a session that the store did not have (expired or destroyed), Session kept that id and wrote the new guest session under it.
3. commit() sent the session cookie on each response. A late response could put back an id that the browser had left, for example the guest id after a login that regenerated the session.
4. In Redis, a tagged() call between tag() and write() removed the new session from the user's set, because the session had no data yet.

Also, the redis and database stores only sign the data, and the japa plugins always wrote the test session to the memory store.

Solution

One commit for each change:

• Stores do not write back a destroyed session. A store serves one request. It keeps the ids that it found on read. For these ids, the write updates the session only if it still exists: SET … XX in Redis, UPDATE without INSERT in SQL, a file opened with r+, and attribute_exists in DynamoDB. A new session is written as before. SessionCollection is a singleton, so it now makes a new store for each operation.
• renewMissingSessionId option (default false). In initiate(), if the store does not find the id from the cookie, the session gets a new randomUUID() and is fresh. The id of an ended session is not used again. It is opt-in because a session without data then gets a new id on each request, and some apps use session.sessionId as a key for an empty session.
• refreshCookie option (default true, so no change for existing apps). With false, the session cookie is sent only when the session id changes or when the browser did not send one. Tradeoff: the cookie Max-Age is not refreshed, so use this option with clearWithBrowser and let the store expire inactive sessions.
• Tag and write are atomic. For a new session, tag() keeps the user id and write() adds the session to the user's set in the same MULTI (standalone Redis), or stores user_id in the same query as the data (SQL). tag() also applies immediately to a session that exists, so SessionCollection.tag() continues to work. For a session that the store read, the write does not tag it again, so an untag() from another request stays. Redis Cluster refuses a MULTI over keys of different slots, so on a cluster the store sets the data and then adds the id, outside a transaction.
• encrypt option for stores.redis() and stores.database() (default false). The data is encrypted with the encryption service, with the session id as purpose.
• japa plugins use the configured store. For the cookie store, they use the memory store, because the cookie store needs an HTTP request. Each call of the test client gets a new store, so a session read before a logout can be set again. With refreshCookie: false, the api client loads the session id it sent when the response has no session cookie. SessionClient now waits for write() and destroy().

Example

// config/session.ts
export default defineConfig({
  age: '2h',
  clearWithBrowser: true,
  refreshCookie: false,
  renewMissingSessionId: true,
  store: 'redis',
  stores: {
    redis: stores.redis({ connection: 'main', encrypt: true }),
  },
})

Behavior changes

No option changes its default, so the session id, the cookie and the stored data format stay as before. These behaviors change:

• A write does not bring back a session that another request destroyed during the request. This is the fix.
• The database store tag() does not create a row for a session that has no data.
• When you enable encrypt, the existing sessions cannot be read. Each user starts a new session one time.
• With an external store in tests, browserContext.close() now waits for the test session to be destroyed, and rejects if the store fails.

Tests

Each change has a test that fails without the fix, except the two items below. 244 tests pass on sqlite, postgres and mysql, with real redis and dynamodb-local.

Not covered:

• No test makes the file store write fail part way. With ulimit -f 2, the write of a session that the store read now rejects with EFBIG instead of leaving a truncated file.
• No test runs on Redis Cluster, because the CI has no cluster. The cluster path was checked by hand on a local one-node cluster: before the fix, the write of a tagged session failed with CROSSSLOT. On a cluster, a tagged() call that reads the set before the data and removes the id after the SADD can still drop the session.
• The memory store does not have the guard of the first change.
• No test fails without the await fix in SessionClient.
• The file store r+ write against a concurrent delete is not tested on Windows.
• With refreshCookie: false, an empty guest session gets a new id on each request, so its cookie is still sent each time.