

Why sessions are bad - coderdude
http://groups.google.com/group/webpy/browse_thread/thread/2870837302e90df0/eaec76f0d202e228

======
ryanf
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."

------
robbles
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...

~~~
kls
OAuth and SAML are both stateless web compatible authentication mechanisms.
Neither are nasty hacks and neither require the dreaded browser login prompt.

------
alanh
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.

~~~
kls
_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.

------
gregjor
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.

~~~
masklinn
> 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)

------
invalidOrTaken
I read this, and I still didn't understand why sessions are bad. Is he talking
about sessions as distinguished from other cookies?

~~~
kls
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.

~~~
quanticle
[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?

~~~
kls
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.

------
dous
This, btw, is a thread from 2008.

