Hacker News Reader

Comment by yuvadam | Hacker News Reader

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.

View on HN

They do, and they are signed, but they still have issues like this which are so easily mitigated by just using a goddamn server.

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.

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

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.

Reply on news.ycombinator.com