CODEWITHSUNDEEP
sessioncookiesplayframework
Kazuya Tomita
Kazuya Tomita

Reputation: 697

The use case of Client side session in Play

In play, the word "client-side session" seems to mean that all datas are stored in a cookie in the client during session. And PHP, which is known to use "server-side session" , I think it is possible to store all datas in the cookie. Probably the difference is whether the cookie is singed with a secret key or not, but I am not sure. In a normal session known as "server-side session", you can set a cookie which has a session ID and then the server should deal with the session ID and can find the related specified values. In this session, the client has only the session ID, which is just a long number. And specified datas are stored in the server-side, so I assume it is called "server-side session".

I know in Play this approach is also possible, which means the client has the session ID and the server has some specified datas normally in the cache. Play enables pushing all datas into the client's cookie, signed with a secret key, and my question is under what types of implements should we use the "client-side session"? I don't imagine and in a official document about Play's session doesn't mention so deeply.

What is the use case? When do you implement the client-side session? Any comment or answer should be highly appreciated.

Upvotes: 0

Views: 521

Answers (1)

Timo Ohr
Timo Ohr

Reputation: 7947

The problem with server side sessions is that you have to replicate them across all your servers.

Websites are usually deployed on multiple instances, with a load balancer in front that more or less randomly routes your requests to an application instance. For a session to work, all servers need to be able to access it, either by storing the sessions in a central datastore like a database, or by replicating them. This makes scaling somewhat more difficult, because you either have to introduce a bottleneck through your database, or because you have to set up a complicated replication scheme.

Client side sessions have the advantage that all the required data is contained in the request itself, so your servers can remain stateless and don't need to communicate with each other. The downside to that is that the size of your requests will increase if your sessions contain a lot of data, and it is resubmitted on every request.

The most common use case for sessions though is usually just storing a User ID or similar to indicate that a user is logged in, which is usually not larger in size than a session token. So in this case, client side sessions are much more efficient, by for example saving you a round trip to the database to retrieve your session.

Another disadvantage of client side sessions is security, since server side sessions are conceptually much harder to temper with, but Play mitigates that issue reasonably well by signing them. Just make sure not to store any sensitive data in your sessions that people aren't supposed to be able to read.

So essentially, if your sessions are very small, client side sessions might be the way to go. If they are large, or contain sensitve data, you should go with server side sessions.

Upvotes: 3

Related Questions