storing sessions on server.. why?

views:

104

answers:

+1 Q:

storing sessions on server.. why?

Hi I have been using Flask for some time now and I am really enjoying the framework. One thing that I fail to understand is that in almost all other places they talk about storing the session on the server and the session id on the client, which would then identify the session.However after using flask , I dont feel the need to do so. Saving the session as a cookie on the client cryptographically, serves my purpose and seems quite secure too, the only thing being I am unable to encrypt the session keys for eg:- session['life']='the great one' would appear as life='gfhjfkjdfa some encryption kj'in the cookie saved on the client. But how would that matter as it is still encrypted. I am sure that people here know things much better than I do, so request someone to please clarify :-)

+3 A:

If the session data is needed at the server, it makes sense to store it at the server. It keeps down the data bulk sent back and forth from the client. Also, cookies have a limit on the amount of data they can store.

Ned Batchelder 2010-10-16 13:05:52

+1 for a nice, concise summary.

Justin Ethier 2010-10-16 13:10:55

Thanks Ned! but in majority of the cases wont that data bulk be negligible.

Alice 2010-10-16 13:19:12

But yes, +1 as I feel this to be one valid reason which I guess I can safely ignore on my app :-).However still waiting for some more answers to this!

Alice 2010-10-16 13:36:45

+3 A:

Even if your data is encrypted, the user could still roll back their cookie to a previous state (unless you start encoding one-time IDs etc)

e.g. cookie says the user has 100 credits, user spends 100 credits, they get a new cookie saying they have 0 credits. They could then restore their previous cookie (with 100 credits).

Depending how you encrypt the cookie, the user may also be able to delete keys, insert bogus data etc too.

Nick 2010-10-16 13:16:29

Thanks Nick! But again wont encryption take care of it.for eg session[credits]=100 would be saved as something like credits='agfkalh some encryption agakh'. And if the secret key used to encrypt the cookie is unknown to the user and is hard enough , how would he be able to cause any change.I mean he sure can go ahead deleting keys and inserting some bogus data but as long as he is unable to decrypt the cookie , how could any problem be created.

Alice 2010-10-16 13:26:37

If 100 credits is encrypted as credits="abc", the user can see this, and knows that "abc" will be decrypted to 100. They don't need to be able to decrypt it themselves. So they can spend all the credits, then set credits to "abc" again.There are ways to prevent this, but it's not really worth the hassle when you can just store the data on the server.

Nick 2010-10-16 14:21:09

Thanks ! .. that was something that I was looking for actually, just did not cross my mind..

Alice 2010-10-16 18:39:50

This is basically a replay attack: http://en.wikipedia.org/wiki/Replay_attack.

bjarkef 2010-10-30 18:54:05

+1 A:

In addition to the points already mentioned above

Users can disable cookies using their browser settings. A lot of antivirus scanners also scan and flag cookies as a risk because of which which can also result in cookies not being allowed on the users computer.
Cookies can be deleted by the user even in the middle of his session. (In fact, i inadvertently did that the other day when one my PC scans listed the tracking cookies...and i just clicked "Clean" and they were all gone). In case the user happens to delete the cookies, the users state will be lost.

If you use cookies to manage the entire state, you are always dependant on the client environment and its settings. In as such, you will probably atleast need a fall back mechanism in case the cookies are deleted / disabled etc in order for your application to work correctly.

InSane 2010-10-16 13:38:42

Thanks InSane for replying , but that was not what I actually wanted to know :-) . What I wanted to know was why to store any session related data on the server. I mean even if you store session variables on the server,you would have to store the session id on the client in a cookie.To answer what you have said, by deleting cookies , the user actually does more harm to himself as he loses the session. He might actually be logged out if he is logged into the site, or he might even lose some data. As far as disabling cookies are concerned,I guess the fallback has to be worked on . Thanks

Alice 2010-10-16 13:42:24

@Alice - Actually that was the point i was trying to make. Basically, you need to store session related data on server because storing it on the client is not reliable due to examples pointed above. When cookies are disabled, the sessionid is usually passed in a querystring as its just one value. Sessions can be made independant on cookies - even for the session id

InSane 2010-10-16 13:46:04

"the sessionid is usually passed in a querystring as its just one value"-Yes that sounds good..1 up... Thanks

Alice 2010-10-16 13:49:54

+1 A:

The SecureCookie implementation Flask uses does not encrypt the values. The only thing that is being ensured is that the user cannot modify the cookie without knowing the secret used by the application.

DasIch 2010-10-30 08:21:34

ansaurus

tags:

views:

answers:

storing sessions on server.. why?

related questions