Devise, like any Rails application, uses Rails’ session storage mechanisms to manage user sessions. Where Devise stores session data on the server side depends on the session store configuration in your application. Here are the common methods:
1. Cookie-Based Session Storage (Default)
By default, Rails applications (including those using Devise) use cookie-based sessions:
• Encrypted Cookies: The session data is stored directly in cookies on the client side. When a user logs in, Devise creates a cookie that contains a session ID and other relevant session data (like user ID).
• Server-Side: The actual session data is not stored on the server in this case. Instead, the server uses the cookie to reference session data. This data is encrypted and signed to prevent tampering.
• Cookie Name: The default cookie name is typically _your_app_session (where your_app is the name of your application).
2. Database-Backed Session Storage
If you have configured your Rails application to use database-backed sessions, Devise will store session data in a database table. This requires additional setup:
1. Set Up Active Record Session Store: You can use the activerecord-session_store gem to enable session storage in the database. Add it to your Gemfile:
gem ‘activerecord-session_store’
2. Create the Sessions Table: After installing the gem, create the sessions table by running:
rails generate active_record:session_migration
rails db:migrate
3. Configure Session Store: Update your session store configuration in config/initializers/session_store.rb:
Rails.application.config.session_store :active_record_store, key: '_your_app_session'4. Session Data in Database: With this setup, session data will be stored in a table named sessions. The table typically includes:
• id: The session ID.
• data: A serialized version of the session data.
• created_at: Timestamp of when the session was created.
• updated_at: Timestamp of when the session was last updated.
3. Cache-Based Session Storage
Rails can also be configured to store sessions in a caching store, like Redis or Memcached. This is set up similarly in config/initializers/session_store.rb:
Rails.application.config.session_store :cache_store, key: '_your_app_session'In this case, session data will be stored in the configured cache store. The session ID will still be stored in a cookie on the client side.
4. File-Based Session Storage
Although less common, Rails can also store session data in files on the server. You can configure this in config/initializers/session_store.rb:
Rails.application.config.session_store :file_store, key: '_your_app_session'In this case, session data is stored in the filesystem, usually under a tmp/sessions directory.
Summary
• Default (Cookie-Based): Session data is stored in encrypted cookies on the client side; no server-side storage.
• Database-Backed: Configured via activerecord-session_store, with session data stored in a sessions table in the database.
• Cache-Based: Uses a cache store like Redis, with session IDs stored in cookies.
• File-Based: Session data is stored in files on the server’s filesystem.
To determine where your application stores session values, check your session store configuration in config/initializers/session_store.rb and any additional configuration related to Devise.
In summary, by default, if you do not set anything in session_store.rb, Devise and Rails will use cookie-based session storage, meaning session data is stored client-side in encrypted cookies without any server-side session management. This case, in my opinion, hacker can copy the cookie session and use it to access our web even user signed out. Because devise uses same secret key to decrypt the session and it couldn’t expire the session right away if hacker copied already the session in advance. We shouldn’t use the default Cookie-based but use other methods above. Cache-based for fast and database or file based for ease of management.