Ask HN: Client side or server side sessions? | Hacker News Reader

Ask HN: Client side or server side sessions?

7 pointscodegeek12 comments

I have been doing a lot of reading lately on sessions and cookies. I am almost obsessing over web security while learning Python/Flask and building some small apps to teach myself.

I know there is probably not a one size fits all kind of answer for this but what are the pros and cons of client side vs. server side sessions ? I was thinking of building server side session (using redis). Thoughts?

View on HN

Client-side sessions are nice because they are simple and you don't need a backend in your server.

But they have cons too:

- If a user changes his password, other sessions will keep active until they expire. This is a problem when (and not if) an account gets compromised. You can fix this easily, for example, including a token for each user that changes when changing the password, but then it defeats the point of client-side: you have to store the last token somewhere in your server.

- With the default implementation of Flask, if your secret key somehow leaks, apart of the obvious problem, anybody could execute arbitrary code in your server. You can fix this easily and without any serious consequences (apart from kicking out all your already logged users) by using JSON to serialize the cookies instead of Pickle: https://gist.github.com/2501926

- You are limited to 4 KB of data. In a server-side solution the user has only a session ID that gets associated to all the data you want in your database.

Thanks I have looked through this already. I even used the snippet to use itsdangerous module which seems more secure. But how do I tie all that in a session ? More importantly, client side or server side?

I don't know if I understood your question correctly. If you use Redis (or whatever backend) you don't need to sign the cookie with itsdangerous (or whatever module). You just generate a SID and stick it into a cookie: http://flask.pocoo.org/snippets/75/

Assuming your client-side sessions are stored in cookies, be aware of doing multiple simultaneous requests. The order in which the server processes them could be different than the order the client processes the results. This can lead to overwriting a session with an older version of the same one.

Unless you are only doing one request at a time or you don't mind rolling back to older session data, avoid cookie-based client side sessions.

I have decided to go with server side session to store session data. But I will use signed cookie to transfer the session id b/w client/server.

What I have opted for when doing modern web development is to eschew the idea of session all together. Decoupling authorization and authentication from data storage is one of the advantages while the other is that you do not run into the standard anti-patterns that session creates on the web. With AJAX style request you can exchange authentication and authorization tokens like SAML or oAuth. This can be done by adding authorization headers to the payload, and employing some form of salted encryption. Given that I am not a security expert, I tend to use patterns and encryption algorithms that the security community has endorsed. Some of the more comprehensive JavaScript frameworks like Dojo have crypto implementations. From there I tend to use a cache on the client side, to store transient data that needs to live from request to request and cannot be retained in memory for whatever reason.

You don't understand sessions, it seens.

If you don't mind explaining, I would appreciate. I seriously want to learn and understand about sessions and best practices. been googling and reading for last 2 days.

>>I am almost obsessing over web security ..

If you need more security why not use https all the time and better use two factor authentication?

BTW, would you mind explaining what is a client side session? Share a link may be? Really, I have never heard of them-

By client side session, I mean that the session related data will be stored on client side (in a cookie) instead of server side (database, files etc.).

Generally speaking when it comes to any client-server communications, nothing stored on the client can be trusted to be unaltered out of band from your application logic.

There are very few situations in which I'd store anything on the client other than a basic session id representing server-side state.

This is what I have settled on so far btw.

1. Store session data on server side (use redis for storage)

2. Only exhcnage session id b/w client and server using cookies (serialized using pickle ?)

3. Regenerate session id after login ? Is this needed though ?

Reply on news.ycombinator.com