Class: ActionDispatch::Session::CookieStore
- Inherits:
-
Rack::Session::Abstract::ID
- Object
- Rack::Session::Abstract::ID
- ActionDispatch::Session::CookieStore
- Includes:
- Compatibility, SessionObject, StaleSessionCheck
- Defined in:
- 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 their user_id
without knowing your app’s secret key, but can easily read their 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:
Rails.application.config.session_store :cookie_store, key: '_your_app_session'
Configure your secret key in config/secrets.yml:
development:
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 the secret key will invalidate all existing sessions!
Instance Method Summary collapse
- #destroy_session(env, session_id, options) ⇒ Object
-
#initialize(app, options = {}) ⇒ CookieStore
constructor
A new instance of CookieStore.
- #load_session(env) ⇒ Object
Methods included from SessionObject
#loaded_session?, #prepare_session
Methods included from StaleSessionCheck
Methods included from Compatibility
Constructor Details
#initialize(app, options = {}) ⇒ CookieStore
Returns a new instance of CookieStore.
60 61 62 |
# File 'lib/action_dispatch/middleware/session/cookie_store.rb', line 60 def initialize(app, ={}) super(app, .merge!(:cookie_only => true)) end |
Instance Method Details
#destroy_session(env, session_id, options) ⇒ Object
64 65 66 67 68 69 |
# File 'lib/action_dispatch/middleware/session/cookie_store.rb', line 64 def destroy_session(env, session_id, ) new_sid = generate_sid unless [: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
71 72 73 74 75 76 77 |
# File 'lib/action_dispatch/middleware/session/cookie_store.rb', line 71 def load_session(env) stale_session_check! do data = (env) data = persistent_session_id!(data) [data["session_id"], data] end end |