Class: ActionDispatch::Session::CookieStore

Inherits:
Rack::Session::Abstract::ID
  • Object
show all
Includes:
Compatibility, SessionObject, StaleSessionCheck
Defined in:
actionpack/lib/action_dispatch/middleware/session/cookie_store.rb

Overview

This cookie-based session store is the Rails default. It is dramatically faster than the alternatives.

Sessions typically contain at most a user_id and flash message; both fit within the 4K cookie size limit. A CookieOverflow exception is raised if you attempt to store more than 4K of data.

The cookie jar used for storage is automatically configured to be the best possible option given your application’s configuration.

If you only have secret_token set, your cookies will be signed, but not encrypted. This means a user cannot alter his user_id without knowing your app’s secret key, but can easily read his user_id. This was the default for Rails 3 apps.

If you have secret_key_base set, your cookies will be encrypted. This goes a step further than signed cookies in that encrypted cookies cannot be altered or read by users. This is the default starting in Rails 4.

If you have both secret_token and secret_key base set, your cookies will be encrypted, and signed cookies generated by Rails 3 will be transparently read and encrypted to provide a smooth upgrade path.

Configure your session store in config/initializers/session_store.rb:

Myapp::Application.config.session_store :cookie_store, key: '_your_app_session'

Configure your secret key in config/initializers/secret_token.rb:

Myapp::Application.config.secret_key_base 'secret key'

To generate a secret key for an existing application, run ‘rake secret`.

If you are upgrading an existing Rails 3 app, you should leave your existing secret_token in place and simply add the new secret_key_base. Note that you should wait to set secret_key_base until you have 100% of your userbase on Rails 4 and are reasonably sure you will not need to rollback to Rails 3. This is because cookies signed based on the new secret_key_base in Rails 4 are not backwards compatible with Rails 3. You are free to leave your existing secret_token in place, not set the new secret_key_base, and ignore the deprecation warnings until you are reasonably sure that your upgrade is otherwise complete. Additionally, you should take care to make sure you are not relying on the ability to decode signed cookies generated by your app in external applications or Javascript before upgrading.

Note that changing digest or secret invalidates all existing sessions!

Instance Method Summary collapse

Methods included from SessionObject

#loaded_session?, #prepare_session

Methods included from StaleSessionCheck

#stale_session_check!

Methods included from Compatibility

#generate_sid

Constructor Details

#initialize(app, options = {}) ⇒ CookieStore

Returns a new instance of CookieStore.



59
60
61
 
# File 'actionpack/lib/action_dispatch/middleware/session/cookie_store.rb', line 59

def initialize(app, options={})
  super(app, options.merge!(:cookie_only => true))
end

Instance Method Details

#destroy_session(env, session_id, options) ⇒ Object 



63
64
65
66
67
68
 
# File 'actionpack/lib/action_dispatch/middleware/session/cookie_store.rb', line 63

def destroy_session(env, session_id, options)
  new_sid = generate_sid unless options[:drop]
  # Reset hash and Assign the new session id
  env["action_dispatch.request.unsigned_session_cookie"] = new_sid ? { "session_id" => new_sid } : {}
  new_sid
end

#load_session(env) ⇒ Object 



70
71
72
73
74
75
76
 
# File 'actionpack/lib/action_dispatch/middleware/session/cookie_store.rb', line 70

def load_session(env)
  stale_session_check! do
    data = unpacked_cookie_data(env)
    data = persistent_session_id!(data)
    [data["session_id"], data]
  end
end