Why sessions are bad
groups.google.com
groups.google.com
Unless you're totally fine with a HTTP authentication popup every time you visit the site, that is...
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.
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.
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)
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.
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?
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.