Features
- Multiple Storage Strategies: Includes memory, cookie, and file-based session storage strategies for different use cases
- Flash Messages: Support for flash data that persists only for the next request
- Session Security: Built-in protection against session fixation attacks
Installation
Usage
The following example shows how to use a session to persist data across requests. The standard pattern when working with sessions is to read the session from the request, modify it, and save it back to storage and write the session cookie to the response.session middleware in fetch-router to automatically manage the session for you.
Flash Messages
Flash messages are values that persist only for the next request, perfect for displaying one-time notifications:Regenerating Session IDs
For security, regenerate the session ID after privilege changes like a login. This helps prevent session fixation attacks by issuing a new session ID in the response.session.regenerateId(true). This can help to prevent session fixation attacks by deleting the old session data when the session is saved. However, it may not be desirable in a situation with mobile clients on flaky connections that may need to resume the session using an old session ID.
Destroying Sessions
When a user logs out, you should destroy the session usingsession.destroy().
This will clear all session data from storage the next time it is saved. It also clears the session ID on the client in the next response, so it will start with a new session on the next request.
Storage Strategies
Several strategies are provided out of the box for storing session data across requests, depending on your needs. A session storage object must always be initialized with a signed session cookie. This is used to identify the session and to store the session data in the response.Filesystem Storage
Filesystem storage is a good choice for production environments. It requires access to a persistent filesystem, which is readily available on most servers. And it can scale to handle sessions with a lot of data easily.Cookie Storage
Cookie storage is suitable for production environments. In this strategy, all session data is stored directly in the session cookie itself, which means it doesn’t require any additional storage. The main limitation of cookie storage is that the total size of the session cookie is limited to the browser’s maximum cookie size, typically 4096 bytes.Memory Storage
Memory storage is useful in testing and development environments. In this strategy, all session data is stored in memory, which means no additional storage is required. However, all session data is lost when the server restarts.External Storage
For production applications with multiple servers, you may want to use external storage like Redis or Memcache:@remix-run/session-storage-redis- Redis-backed session storage@remix-run/session-storage-memcache- Memcache-backed session storage
API Reference
Session
Represents a user session with key-value data storage.
Methods:
get(key: string)- Get a value from the sessionset(key: string, value: any)- Set a value in the sessionhas(key: string)- Check if a key exists in the sessionunset(key: string)- Remove a key from the sessionflash(key: string, value: any)- Set a flash message (available only on next request)regenerateId(deleteOld?: boolean)- Generate a new session IDdestroy()- Mark the session for destruction
id: string- The session IDdata: Record<string, any>- The session data
SessionStorage
Interface for session storage implementations.
Related Packages
cookie- Cookie parsing and serializationfetch-router- Router with built-in session middlewaresession-middleware- Automatic session management middleware