Rails sessions and cookie jars

Direct Answer

A browser cookie is a small value sent with matching HTTP requests; Rails exposes plain, signed, and encrypted cookie jars. A Rails session is a server-side interface whose storage depends on the configured session store: CookieStore keeps the session payload in an encrypted cookie, while cache or database stores keep only an identifier in the cookie.

Deep Dive & Architecture

A server sends a Set-Cookie response header containing a value and attributes. The browser stores it, then includes it in later requests only when scope and policy permit. Secure limits transmission to HTTPS, HttpOnly prevents normal client-side JavaScript access, SameSite affects cross-site sending, and domain/path narrow where the cookie is attached. These flags reduce risk but do not turn arbitrary cookie content into a safe place for secrets.

Rails' plain cookies[:theme] jar is useful for a non-sensitive preference. The value can be read and changed by the user. cookies.signed[:account_id] adds a verifier so Rails rejects tampered values, but the user can still read the payload. cookies.encrypted[:draft] encrypts and signs. The cryptographic keys derive from application secrets, so secret rotation needs a planned cookie rotation or existing values become unreadable.

The session interface looks like a hash regardless of its store. CookieStore serializes the session payload into the protected session cookie, avoiding a server lookup but inheriting cookie size and replay limits. CacheStore or an Active Record-backed store keeps state server-side and uses the cookie to identify it. Those stores make central invalidation possible but add storage availability, cleanup, and lookup concerns.

For login, store a stable identifier rather than an entire model object. A helper loads the current record and still checks present-day account status. Renew or reset the session when authentication changes to defend against session fixation. Remove session state on logout, use an expiry appropriate to the risk, and avoid logging cookie or authorization values.

CSRF and XSS remain separate concerns. Cookie credentials are attached automatically by browsers, so state-changing requests need Rails' CSRF protections unless the architecture has a justified alternative. HttpOnly can reduce token theft through JavaScript, but an XSS payload can still act as the user. Sessions and cookies are mechanisms; safe authentication depends on the surrounding request and browser model.

When debugging, inspect the browser's cookie attributes and size, then confirm the configured Rails session store and key. Do not paste a production cookie into logs or tickets: even an opaque-looking or encrypted value remains an active credential while valid.

Code Example

class SessionsController < ApplicationController
  def create
    user = User.authenticate_by(email: params[:email], password: params[:password])
    return head :unauthorized unless user

    reset_session
    session[:user_id] = user.id
    cookies[:theme] = { value: "dark", same_site: :lax, secure: Rails.env.production? }
    redirect_to dashboard_path
  end

  def destroy
    reset_session
    redirect_to root_path
  end
end

The session holds only the authenticated identity; the plain cookie stores a non-sensitive visual preference.

Common Mistakes & Pitfalls

Claiming every Rails cookie is encrypted or that every Rails session is stored in the browser.