Server based lookups have their own problems. An attacker can guess a session ID and spoof that customer. Storing hundreds of thousands of session IDs on disk or in the database can lead to performance problems. You'd leak huge amounts of information if someone were to gain access to the database or filesystem where these cookies are stored.
You can argue about solutions to each of these. My point is that each solution has their own problems. IMO, play's solution has worked well so far, making it easy to scale horizontally. I've been using play for 3 years. One security issue in 3 years, with a quick patch applied, is acceptable. Before that we used PHP, and we had many problems dealing with the huge volume of sessions to be handled.
Comments
Server based lookups have their own problems. An attacker can guess a session ID and spoof that customer. Storing hundreds of thousands of session IDs on disk or in the database can lead to performance problems. You'd leak huge amounts of information if someone were to gain access to the database or filesystem where these cookies are stored.
You can argue about solutions to each of these. My point is that each solution has their own problems. IMO, play's solution has worked well so far, making it easy to scale horizontally. I've been using play for 3 years. One security issue in 3 years, with a quick patch applied, is acceptable. Before that we used PHP, and we had many problems dealing with the huge volume of sessions to be handled.
ID is random UUID, session is in Redis as an expiring key.