Cookie-based sessions have many, very reasonable, use cases.

You are also clearly neglecting the fact that proper session cookies are _always_ cryptographically signed and cannot be tampered with, if properly implemented.

Using a server based session storage is simple as long as your whole app lives in one datacenter and all frontend hosts can reach said server. Once you have app servers in multiple datacenters (e.g. for geo loadbalancing) and want to provide a seamless login no matter which server the user ends up on server based session storage just gets a lot harder. (Apart from having to handle a massive write load which used to cause major pain with mysql, myisam and database based session storage, but these times are luckily over).

Redis is an ideal data store for this kind of thing, will be doubly so once we have Redis Cluster.

But still, if your frontend hosts can't reach your database, you have far bigger problems than your sessions not working.

There's a whole class of applications that can happily serve data that slightly stale, so they can use any kind of replication/cluster to make data available on multiple datacenters, even if that makes for a little lag. Session data however must be instant, so that requires a very fast and stable replication, making the problem much harder. Redis is particularly unsuited to serve such data since it's single-master replication only. It's totally fine in a single datacenter, but fails once you move out. Redis cluster may or may not be a solution, but it's not here yet anyways.

redis is single master so all non-local web servers will be extra slow. It is a poor solution for multi datacenter.

What your forgetting is the reason people use frameworks such as Rails - so they don't have to care about these types of details.

I agree that simply storing everything in the cookie is wrong, and Rails should never have been doing this - hell, even CodeIgniter (PHP) has DB based sessions.

But most Rails devs (myself included) are just about getting shit done, we don't know everything that's going on under the bonnet, and we don't want to.

Please don't speak for others, especially when you claim that you don't know what you're talking about in the same sentence.

And FYI CookieStore is just the default, because it's convenient and require no dependency. But you're juste a line of configuration away to switch the sessions inside your DB or Memcache or whatever.

> But most Rails devs (myself included) are just about getting shit done, we don't know everything that's going on under the bonnet, and we don't want to.

I love getting shit done.

It's my job as a professional to know everything that's going on "under the bonnet."

I'm still learning.

But it's my job to try.

It's a pretty widespread practice. I think it's the Rails default.

Sure, it's the default, but don't people realize never to trust clientside data? I don't know if CookieStore is signed or not, but I generally assume even if I sign the data it's not safe.

It's not that hard to just set up a Redis or whatever store to handle stuff like this, I never understood why people whouldn't bother.

Cookie store has always been signed and in rails 4 it's encrypted.

Very sloppy it wasn't encrypted from day 1 imo.

most popular web frameworks don't put data in the cookie, signed or not. yes it introduces different problems, but avoids this one.

How would you do it with redis exactly?

Same way ActionDispatch::Session::CacheStore does.

All session stores use a cookie to store a unique ID for each session...For most stores, this ID is used to look up the session data on the server, e.g. in a database table.

(obviously you'd substitute Redis for the database table mentioned above)