That's a bit surprising. I'd be interested to read the reasoning behind this design decision as most frameworks I have used store session data in a database rather than directly in the cookie. Well I guess there is a pretty damn good reason given Rails' reputation.
Rails' default session is cookie store, highly recommended is DB. It's a config issue that depends on your app's particular DB setup, so default isn't DB. But in session_store.rb you'll see this comment recommending against the default:
# Use the database for sessions instead of the cookie-based default,
# which shouldn't be used to store highly confidential information
# (create the session table with "rails generate session_migration")
# ShopMobile::Application.config.session_store :active_record_store
# Your secret key for verifying the integrity of signed cookies.
Does this mean that if you use redis/db-backed sessions you can safely ignore this secret_token parameter completely or even delete this initializer?
UPDATE: I just tried to remove it from our environment, and everything seems fine. Unless I'm missing something out, I'd say that's a far better and easier solution overall. It gives you much better control over you session + you don't have to worry about this configuration variable.
It is often useful to not have to store anything server-side and just round-trip signed data in the cookie. Of course, using a format that can execute code on deserialisation is still a bad idea: a successful attack on the signature should at most let someone impersonate a user, not do anything to an app.
http://daniel.fone.net.nz/blog/2013/05/20/a-better-way-to-ma...