Why sessions are bad(groups.google.com)
groups.google.com
Why sessions are bad
http://groups.google.com/group/webpy/browse_thread/thread/2870837302e90df0/eaec76f0d202e228
13 comments
It's amazing that someone could write something with this title and forget to include any actual reasons why sessions are bad. He probably should have just called it "Sessions Are Bad."
This makes no sense to me at all. Barring some pretty nasty hacks, theres no other way to implement a lot of the features users expect in modern web apps without sessions.
Unless you're totally fine with a HTTP authentication popup every time you visit the site, that is...
Unless you're totally fine with a HTTP authentication popup every time you visit the site, that is...
OAuth and SAML are both stateless web compatible authentication mechanisms. Neither are nasty hacks and neither require the dreaded browser login prompt.
Wow, terrible. Old news, no real solution here, just the same old realization that “the web should be stateless” and the same, obvious retort that, you know, we more or less need sessions to provide security for users.
we more or less need sessions to provide security for users
This is not entirely true, SAML tokens are a very good solution for stateless authentication and authorization. The nice part is that they can provide third party authorization as well.
Session creates so many anti-patterns that it is no wonder that traditional web 1.0 development is in the state it is in. There are a multitude of other solutions out there that provide very clean stateless programming patterns.
The problem with session is that once a developer falls on it as a crutch it begins to be used for all manner of bad programming habits.
Sun had a very good product called OpenSSO that did stateless authentication and authorization unfortunately it was one of the project Oracle killed off.
This is not entirely true, SAML tokens are a very good solution for stateless authentication and authorization. The nice part is that they can provide third party authorization as well.
Session creates so many anti-patterns that it is no wonder that traditional web 1.0 development is in the state it is in. There are a multitude of other solutions out there that provide very clean stateless programming patterns.
The problem with session is that once a developer falls on it as a crutch it begins to be used for all manner of bad programming habits.
Sun had a very good product called OpenSSO that did stateless authentication and authorization unfortunately it was one of the project Oracle killed off.
warning: article is from 2008, and is an advance ad for a book that hasn't been published yet.
cookies are limited to 4K (not enforced uniformly by browsers) and the total number of cookies and the number from any single domain are also (theoretically) restricted. server-side sessions don't have these limits (or don't have to). author seems unaware of this when he espouses cookies instead of sessions. he also doesn't address the obvious security problems of maintaining state in cookies and form fields, where anyone can fiddle with it.
cookies are limited to 4K (not enforced uniformly by browsers) and the total number of cookies and the number from any single domain are also (theoretically) restricted. server-side sessions don't have these limits (or don't have to). author seems unaware of this when he espouses cookies instead of sessions. he also doesn't address the obvious security problems of maintaining state in cookies and form fields, where anyone can fiddle with it.
> and the total number of cookies and the number from any single domain are also (theoretically) restricted
Did you mean "practically"? From what I've seen, HTTP specs generally don't set limits (so I would not expect any for cookies), and RFC 2965 is no different: it only sets a lower bound (300 cookies, 20 cookies per unique host or domain, 4k per cookie).
Theoretically (from a strict RFC reading), almost nothing in HTTP is restricted, but implementations tend to disagree at every single level of resolution (and some do pretty damn early)
Did you mean "practically"? From what I've seen, HTTP specs generally don't set limits (so I would not expect any for cookies), and RFC 2965 is no different: it only sets a lower bound (300 cookies, 20 cookies per unique host or domain, 4k per cookie).
Theoretically (from a strict RFC reading), almost nothing in HTTP is restricted, but implementations tend to disagree at every single level of resolution (and some do pretty damn early)
I read this, and I still didn't understand why sessions are bad. Is he talking about sessions as distinguished from other cookies?
Sessions are bad because they try to bolt on a statefull pattern onto a stateless medium. This results in several things the first being no guaranteed terminator in which you have to have a catch all pattern to clean up the trash, the catch all's are not ideal for two reasons both related to the fact that it has to be time based (relying on timing in an none timed operation usually indicates you are doing something very wrong). Anyways if you get the timeout too short you kill the users session and have to create even more workflow to get them back to where they where (if you can). If you get the timeout too long you end up eating up too many server resources. I have seen it happen time and time again as soon as an app starts to experience some load as it grows the teams first reaction is to tighten the session timeout, if a teams first course of action to a scalability issues is to tighten there session timeout, they are in real trouble if they get hit with fast growth.
Session is inherently more difficult to scale horizontally, it creates the need for memory replicator routines or homegrown solutions of syncing all sessions to a DB and replicating it on other boxes. This creates complex infrastructure dependencies that have to be accounted for when you have to scale horizontally again.
As well, developers tend to, over time, uses session as a dumping ground, if they need to carry the shopping cart to the next page they just dump the whole 10 megs of data into the session, there is no way (without setting up monitors) to enforce that session is not becoming bloated.
We had a guy one time dump a 200 meg object in session for ever user (it was 1 years availability for ever hotel in North America). He needed one days data for the confirmation and the user might adjust the dates so he just stuck it in session.
Further, session being a grab bag and global in scope means that even when an object no longer has any reference session still has a reference to it so it just sits there pollution memory. So in essence session creates all the same problems that global variables caused, global variables are considered bad practice these days because of those scoping problems. Some developers get lazy and when they do session is a big lazy enabler.
Contrast these with a stateless patterns and it becomes far more simple, users never time out, so you can pick up an operation 4 days from now, the client holds all of the information to pick up the transaction where it left off. As well since the client and server transfer state between each other scaling horizontally becomes simply an exercise of installing the app on another box and adding it to the route table on a round robin load balancing strategy.
And that is the crux of the issue, session is great when you are building an app that sees no load, so developers write an app that relies on session when they are starting out, it gets them in the mentality of using session so when it does start getting load they are already in the session mentality, so instead of taking a critical look and saying we need to get this app stateless so we can quickly scale horizontally, they stay in the session mentality and start designing solutions to replicate memory, store session in databases and other suck solutions that cure the symptoms. That is usually the beginning of a long painful process that finally end in statelessness.
Session is inherently more difficult to scale horizontally, it creates the need for memory replicator routines or homegrown solutions of syncing all sessions to a DB and replicating it on other boxes. This creates complex infrastructure dependencies that have to be accounted for when you have to scale horizontally again.
As well, developers tend to, over time, uses session as a dumping ground, if they need to carry the shopping cart to the next page they just dump the whole 10 megs of data into the session, there is no way (without setting up monitors) to enforce that session is not becoming bloated.
We had a guy one time dump a 200 meg object in session for ever user (it was 1 years availability for ever hotel in North America). He needed one days data for the confirmation and the user might adjust the dates so he just stuck it in session.
Further, session being a grab bag and global in scope means that even when an object no longer has any reference session still has a reference to it so it just sits there pollution memory. So in essence session creates all the same problems that global variables caused, global variables are considered bad practice these days because of those scoping problems. Some developers get lazy and when they do session is a big lazy enabler.
Contrast these with a stateless patterns and it becomes far more simple, users never time out, so you can pick up an operation 4 days from now, the client holds all of the information to pick up the transaction where it left off. As well since the client and server transfer state between each other scaling horizontally becomes simply an exercise of installing the app on another box and adding it to the route table on a round robin load balancing strategy.
And that is the crux of the issue, session is great when you are building an app that sees no load, so developers write an app that relies on session when they are starting out, it gets them in the mentality of using session so when it does start getting load they are already in the session mentality, so instead of taking a critical look and saying we need to get this app stateless so we can quickly scale horizontally, they stay in the session mentality and start designing solutions to replicate memory, store session in databases and other suck solutions that cure the symptoms. That is usually the beginning of a long painful process that finally end in statelessness.
One point I would like to make on this is when most people say Session is a bad design or an anti-pattern they are generally referring to the server side portion of the design. Basically the server side hash map that serves to approximate the state of the client. There are few that would argue that there is no merit in cookies or storing a proxy in a cookie to identify a user. It is all the junk that gets stored on the server to emulate the state of the client that creates so many issues in web development.
[snip]the client holds all of the information to pick up the transaction where it left off.[/snip]
Have you considered the security implications of this? How do you check to see if your transaction data wasn't maliciously modified by the client?
Have you considered the security implications of this? How do you check to see if your transaction data wasn't maliciously modified by the client?
The first part of any security is to figure out what truly need to be protected and focus your efforts on securing those points. That being said the vast majority of web apps have a very small surface of information that someone would look to exploit mainly being credit cards and to a lesser extent personal information. But session is not the solution to fixing that problem, it is merely, again curing the symptom; the cure is to build your web application so that it solicits, transmits uses and disposes of credit card information in a single state transfer.
Further if you have a sign up where credit info will be stored you should be using a solution that provides you with a proxy of the numbers collected and not the actual number itself. None of this is fixed by session rather session just allows you to design patterns that take jirations to bolt onto HTTP.
As for the transaction data being modified by the client, whether you transmit entire state or snippet of state you have the same issue, at some point if the client is comprised they are comprised you can't secure the client you can only assume that all clients are hostile, session does not fix that fact. In the end, with session based auth, web developers post a form over an SSL connection and receive a proxy ID for that session. If someone hijacks that proxy they become that user, in statless auth you POST some auth info over SSL, if someone hijacks the token they become that user. Session does not make a web application more secure. It just helps developers not think through the ramifications of their design choices. Worse yet it gives developers a false sense of security in which they feel that the information is protected by being in session on the server side, when in fact session hijacking is trivial.
Further if you have a sign up where credit info will be stored you should be using a solution that provides you with a proxy of the numbers collected and not the actual number itself. None of this is fixed by session rather session just allows you to design patterns that take jirations to bolt onto HTTP.
As for the transaction data being modified by the client, whether you transmit entire state or snippet of state you have the same issue, at some point if the client is comprised they are comprised you can't secure the client you can only assume that all clients are hostile, session does not fix that fact. In the end, with session based auth, web developers post a form over an SSL connection and receive a proxy ID for that session. If someone hijacks that proxy they become that user, in statless auth you POST some auth info over SSL, if someone hijacks the token they become that user. Session does not make a web application more secure. It just helps developers not think through the ramifications of their design choices. Worse yet it gives developers a false sense of security in which they feel that the information is protected by being in session on the server side, when in fact session hijacking is trivial.
This, btw, is a thread from 2008.