why sessions are bad

[Aaron Swartz]

Here's an excerpt from the book I'm working on about building
programmable web apps. It almost makes me want to take the sessions
module out of web.py. What do people think? Here it is:

The second major choice [in designing the Web] was that the Web would
be "stateless". Imagine a network connection as your computer phoning
up HQ and starting a conversation. In a stateful protocol, these are
long conversations -- "Hello?" "Hello, welcome to Amazon. This is
Shirley." "Hi Shirley, how are you doing?" "Oh, fine, how are you?"
"Oh, great. Just great." "Glad to hear it. What can I do for you?"
"Well, I was wondering what you had in the Books department." "Hmm,
let me see. Well, it looks like we have over 15 million books. Could
you be a bit more specific?" "Well, do you have any by Dostoevsky?"
(etc.). But the Web is stateless -- each connection begins completely
anew, with no prior history.

This has its upsides. For one thing, if you're in the middle of
looking for a book on Amazon but right as you're about to find it you
notice the clock and geebus! it's late, you're about to miss your
flight! So you slam your laptop shut and toss it in your bag and dash
to your gate and board the plane and eventually get to your hotel
entire _days_ later, there's nothing stopping you from reopening your
laptop in this completely different country and picking up your search
right where you left off. All the links will still work, after all. A
stateful conversation, on the other hand, would never survive a
day-long pause or a change of country. (Similarly, you can send a link
to your search to a friend across the globe and you both can use it
without a hitch.)

It has benefits for servers too. Instead of having each client tie up
part of a particular server for as long as their conversation lasts,
stateless conversations get wrapped up very quickly and can be handled
by any old server, since they don't need to know any history.

Some bad web apps try to avoid the Web's stateless nature. The most
common way is thru session cookies. Now cookies certainly have their
uses. Just like when you call your bank on the phone and they ask you
for your account number so they can pull up your file, cookies can
allow servers to build pages customized just for you. There's nothing
wrong with that.

(Although you have to wonder whether users might not be better served
by the more secure Digest authentication features built into HTTP, but
since just about every application on the Web uses cookies at this
point, that's probably a lost cause. There's some hope for improvement
in HTML5 (the next version of HTML) since they're-- oh, wait, they're
not fixing this. Hmm, well, I'll try suggesting it.[^w])

[^w]: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016742.html

The real problem comes when you use cookies to create sessions. For
example, imagine if Amazon.com just had one URL:
http://www.amazon.com/ The first time you visited it'd give you the
front page and a session number (let's say 349382). Then, you'd send
call back and say "I'm session number 349382 and I want to look at
books" and it'd send you back the books page. Then you'd say call back
and say "I'm session number 349382 and I want to search for
Dostoevsky". And so on.

Crazy as it sounds, a lot of sites work this way (and many more used
to). For many years, the worst offender was probably a toolkit called
WebObjects, which most famously runs Apple's Web store. But, after
years and years, it seems WebObjects might have been fixed. Still, new
frameworks like Arc and Seaside are springing up to take its place.
All do it for the same basic reason: they're software for building Web
apps that want to hide the Web from you. They want to make it so that
you just write some software normally and it magically becomes a web
app, without you having to do any of the work of thinking up URLs or
following REST. Well, you may get an application you can use through a
browser out of it, but you won't get a web app.

[MilesTogoe]

To me the whole idea of some foreign web site writing stuff on your hard
disk is just wrong, and have always thought some sort of session
connection made more sense. The analogy of the customer svc phone call
is a good one, but might have to be a bit clarified and better
contrasted with state vs stateless. gee, and I was kinda liking what
they were doing in Seaside.... and so I'm waiting for the right answer
:) maybe we have to wait for the book :) ps: I've enjoyed reading
some of your blogs (Mr Swartz goes to Washington was great) so try to
keep the same light tone in your book - I'll look forward to reading it.

[Aaron Swartz]

Thanks for the compliment -- it's a pretty light tone; I'm quite happy
with it so far.

[Brent Pedersen]

i wonder if this message is because-of or inspite-of the observation
that 4 of the 5 messages preceding it on the list are regarding
sessions.
that at least shows they're being used. would you take out the cookie
functions too?
i'm just coming back to webpy after a break and i was glad to see the
session stuff fleshed out better.
i'd like to understand how auth digest could be used -- in web.py or
explained in your example as i dont follow how that would work--at
least compared to the ease of using a session.
thanks,
-brentp

[Aaron Swartz]

Cookies can be used reasonably; that's why I say the problem is
session cookies. MoinMoin provides a good example of how to use HTTP
Digest Authentication.

[toomyem]

Aaron,

How do you see sessions can be carried between page requests? Do you want
to replace cookies with urls (e.g. http://some.url/page?sesid=1234)? Or
some other way?

tooymem

--
rootnode rulez ;)

[Aaron Swartz]

> How do you see sessions can be carried between page requests? Do you want
> to replace cookies with urls (e.g. http://some.url/page?sesid=1234)? Or
> some other way?

No, that's even worse. I want to get rid of sessions altogether.

[toomyem]

So how do you want to implement user authentication/authorization in this
case?

toomyem

--
rootnode rulez ;) (chyba)

[Aaron Swartz]

> So how do you want to implement user authentication/authorization in this
> case?

Either Digest Auth or a cookie for the user. In which case the cookie
for the user isn't a session; it just identifies a request coming from
a user.

[jlist]

Hello Aaron,

If it's a multi-step operation, will digest auth or user cookie
help in terms of remembering where the user is in the process?
Or does the user have to start over again?

Thanks,
Jack

[Aaron Swartz]

> If it's a multi-step operation, will digest auth or user cookie
> help in terms of remembering where the user is in the process?
> Or does the user have to start over again?

For multi-step operations, you should design the forms so that all
relevant state is conveyed in the pages themselves. (Obviously the
details depend on the operation.)

[jlist]

Hello Aaron,

Thanks requires a lot of information to be sent back and forth.
When the forms have many fields, and/or when there are many steps
in the operation, it doesn't sound optimal. Or am I missing
anything obvious?

Jack

[toomyem]

So we are going back to the times, when all data was sent back and forth
wth every request. I thought that sessions were invented to aid this
problem, weren't they?

toomyem

--
rootnode rulez ;) (I guess so ...)

[lui...@gmail.com]

For example, how would you do it for a shopping cart?

[Aaron Swartz]

> For example, how would you do it for a shopping cart?

That's a good example. Personally, I'd have a cookie that listed the
product IDs they'd added to the cart and if they went over the
cookie-size limit I'd ask them to create an account.

[lui...@gmail.com]

Sorry if this question is dumb but, isn't it more or less what
sessions do ?
A session stores the id in a cookie and all the other relevant data in
a database. Am I wrog?
How does it differ from what you said?

[Juan Pablo Scaletti]

In fact it's a perfect example of why, even if we use HTTP Digest for
the authentication, the session module is still needed.
With the session module you can just store those IDs directly server-
side without the need of create an account.

[paul jobs]

is there anywhere we can read the beta version of your book now?

[Aaron Swartz]

> is there anywhere we can read the beta version of your book now?

No, this is the first time I've shared anything from it.

[paul jobs]

we use beaker for session cookies so it doesnt matter if webpy has sessions

On 10/21/08, Aaron Swartz <m...@aaronsw.com> wrote:

[paul jobs]

what are the toc, and the kind of content in the book.. im curious as i like reading your blog :)

On 10/21/08, Aaron Swartz <m...@aaronsw.com> wrote:

[Aaron Swartz]

Here's the current TOC:

- Building Programmable Web Sites
- Introduction: A Programmable Web?
- Building for users: designing URLs
- Building for search engines: following REST
- Building for choice: allowing import and export
- Building a platform: providing APIs
- HTML
- JSON
- XML
- RDF
- Building a database: queries and dumps
- SPARQL
- compressed API
- Building for freedom: open data, open source
- open service definition
- open knowledge
- open source
- SQL dumps
- source repositories
- Conclusion: A Semantic Web?

I've written the first three chapters so far.

[Juan Pablo Scaletti]

By the way. Congratulations! I'm looking forward to read that book.

[paul jobs]

Hey Aaron

can we read it online like open source bruce eckel style

http://youfindr.com/thinking_in_python
http://youfindr.com/thinking_in_cpp
http://youfindr.com/bruce_eckel

 

On 10/21/08, Aaron Swartz <m...@aaronsw.com> wrote:

[paul jobs]

is there going to be a chapter about webpy?

On 10/21/08, Aaron Swartz <m...@aaronsw.com> wrote:

[Brett Hoerner]

Like luismgz asked, isn't that exactly what sessions do?

Once they go over the cookie size, they create an account. Now you
have to store some information in your database (a username, a cart
pointing to that username, items pointing to that cart) - it doesn't
matter if they're in their own tables or serialized. And then for the
user to say on each request that "I am user X" you set a cookie that
has some mapping to a user ID, right? Which is exactly what a session
is, right?

I'm not trying to troll, I'm honestly curious here. Am I missing
something?

Brett

[Aaron Swartz]

I think it's reasonable to keep information in a DB tied to an
account, since someone can log back in from somewhere and get at the
data. Whereas you can't log back into your session if you trash your
cookies.

[Brett Hoerner]

Sure, I totally agree. I guess I misunderstood in that I thought you
had something against using a cookie to identify a user, but I see
that you rather mean using a cookie to identify a 'bag of state'.

All clear. :)

Brett

[jgfoot]

On Oct 21, 9:39 am, "Aaron Swartz" <m...@aaronsw.com> wrote:

> (Although you have to wonder whether users might not be better served
> by the more secure Digest authentication features built into HTTP, but
> since just about every application on the Web uses cookies at this
> point, that's probably a lost cause. There's some hope for improvement
> in HTML5 (the next version of HTML) since they're-- oh, wait, they're
> not fixing this. Hmm, well, I'll try suggesting it.[^w])
>
> [^w]:http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/0167...

It isn't a lost cause until you give it up. In a world of wi-fi I
feel increasingly nervous about insecure session cookies. Download
session-hijacking tools like "Hamster and Ferret" to see what I
mean.

In fact, I just wrote a digest authentication plug-in for web.py. The
module is at http://www.autopond.com/digestauth.py and sample code
using it is at http://www.autopond.com/authwall.py .

A lot of smart people worked hard on creating the digest
authentication standard. A lot of less-than-smart people at Microsoft
screwed up its implementation in IE6. But that shouldn't stop us
anymore. Modern browsers do it correctly. As for the biggest user-
interface knock against digest authentication (which you mention on
whatwg), you can use an AJAX call to the server to establish the
authentication without ever confronting the poor confused user with an
ugly "username/password" dialog box.

[pkeane]

Aaron-

Yes, that's key -- "session state" state is hidden from the web (thus
not RESTful). On the web, things (resources) need to have a name
(URI). As you say, a URI that allows an authorized user to get back at
the resource is completely RESTful. Roy Fielding (the fellow who
coined "REST") makes a distinction between resource state and
application state. Resource state is "owned" by the server and
application state is (should be!) "owned" by the client. A cookie
that simply points to a hidden resource on a server by way of a
session token means the client does not really control that resource.
It's a loss of control for the client and a loss of opportunity (that
resource cannot be serendipitously reused) for the server. Lots more
good discussion on this on the rest-discuss list. Excellent REST
gurus there include Roy Fielding, Mark Baker, Aristotle Pagaltzis,
Bill DeHora, etc.

--peter keane

[Aaron Swartz]

> A lot of smart people worked hard on creating the digest
> authentication standard.

It still has the problems I mentioned, right: a) it uses the broken
MD5 hash, b) it requires passwords to be stored in cleartext.

Do you have a demo of the AJAX thing somewhere?

[jgfoot]

MD5's potential for collisions doesn't significantly compromise its
use in this application though, does it? Even SSL uses MD5, and if
it's good enough for SSL...

Digest authentication does not require you to store passwords in
plaintext. You only need to store the hash of
"username:realm:password".

I have the AJAX login thing sitting somewhere on one of my hard
drives; I'll try to dig it out and put it online.

[Aaron Swartz]

> MD5's potential for collisions doesn't significantly compromise its
> use in this application though, does it? Even SSL uses MD5, and if
> it's good enough for SSL...

Wikipedia says that the new version of SSL uses SHA and MD5 and that
browsers refuse to use the MD5-only version.

Wikipedia says that Digest isn't yet broken but that researchers are
getting closer to using the collisions to break Digest.

> Digest authentication does not require you to store passwords in
> plaintext. You only need to store the hash of
> "username:realm:password".

Hmm, that's better than I thought.

[daltonlp]

Hi Aaron,

I think sessions and session cookies are just fine :)

I believe the folks designing the web (http) kept it stateless for
simplicity. If they had added state, they would have to specify how
the state should be stored, represented, exposed, secured, etc.

They also kept http stateless for clarity. They designed a system
for accessing static documents. They weren't interested in web
applications at all.

Mechanisms for persisting state have been added as layers above
http. Which is good, I think.

The current de-facto way to persist a "bag-of-state" is with browser
cookies. Not because they're the best mechanism, but because they're
the most convenient. It just evolved that way.

If you're interested in persisting state differently, you'll need
very clear examples of how to solve current problems in the different
way.

And the examples should probably illustrate the benefits of the new
way.

If you can give such examples, it will influence the evolution of
how people handle state.

To be honest, I'm not seeing the clear benefits of "all relevant

state is conveyed in the pages themselves."

In fact, there is one clear benefit in keeping state *out* of the
pages (in a cookie and a session record on the server). The benefit
is allowing greater separation between display logic and behavior
logic.

Just my 2 cents.

Thanks for posing the question for feedback, and I look forward to
your book.

- Lloyd Dalton




On Oct 21, 8:39 am, "Aaron Swartz" <m...@aaronsw.com> wrote:
> Here's an excerpt from the book I'm working on about building
> programmable web apps. It almost makes me want to take the sessions
> module out of web.py. What do people think? Here it is:
>
> The second major choice [in designing the Web] was that the Web would
> be "stateless". Imagine a network connection as your computer phoning
> up HQ and starting a conversation. In a stateful protocol, these are
> long conversations -- "Hello?" "Hello, welcome to Amazon. This is
> Shirley." "Hi Shirley, how are you doing?" "Oh, fine, how are you?"
> "Oh, great. Just great." "Glad to hear it. What can I do for you?"
> "Well, I was wondering what you had in the Books department." "Hmm,
> let me see. Well, it looks like we have over 15 million books. Could
> you be a bit more specific?" "Well, do you have any by Dostoevsky?"
> (etc.). But the Web is stateless -- each connection begins completely
> anew, with no prior history.
>
> This has its upsides. For one thing, if you're in the middle of
> looking for a book on Amazon but right as you're about to find it you
> notice the clock and geebus! it's late, you're about to miss your
> flight! So you slam your laptop shut and toss it in your bag and dash
> to your gate and board the plane and eventually get to your hotel
> entire _days_ later, there's nothing stopping you from reopening your
> laptop in this completely different country and picking up your search
> right where you left off. All the links will still work, after all. A
> stateful conversation, on the other hand, would never survive a
> day-long pause or a change of country. (Similarly, you can send a link
> to your search to a friend across the globe and you both can use it
> without a hitch.)
>
> It has benefits for servers too. Instead of having each client tie up
> part of a particular server for as long as their conversation lasts,
> stateless conversations get wrapped up very quickly and can be handled
> by any old server, since they don't need to know any history.
>
> Some bad web apps try to avoid the Web's stateless nature. The most
> common way is thru session cookies. Now cookies certainly have their
> uses. Just like when you call your bank on the phone and they ask you
> for your account number so they can pull up your file, cookies can
> allow servers to build pages customized just for you. There's nothing
> wrong with that.

>
> (Although you have to wonder whether users might not be better served
> by the more secure Digest authentication features built into HTTP, but
> since just about every application on the Web uses cookies at this
> point, that's probably a lost cause. There's some hope for improvement
> in HTML5 (the next version of HTML) since they're-- oh, wait, they're
> not fixing this. Hmm, well, I'll try suggesting it.[^w])
>
> [^w]:http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/0167...
>

> The real problem comes when you use cookies to create sessions. For
> example, imagine if Amazon.com just had one URL:http://www.amazon.com/The first time you visited it'd give you the
> front page and a session number (let's say 349382). Then, you'd send
> call back and say "I'm session number 349382 and I want to look at
> books" and it'd send you back the books page. Then you'd say call back
> and say "I'm session number 349382 and I want to search for
> Dostoevsky". And so on.
>
> Crazy as it sounds, a lot of sites work this way (and many more used
> to). For many years, the worst offender was probably a toolkit called
> WebObjects, which most famously runs Apple's Web store. But, after
> years and years, it seems WebObjects might have been fixed. Still, new
> frameworks like Arc and Seaside are springing up to take its place.
> All do it for the same basic reason: they're software for building Web
> apps that want to hide the Web from you. They want to make it so that
> you just write some software normally and it magically becomes a web
> app, without you having to do any of the work of thinking up URLs or
> following REST. Well, you may get an application you can use through a
> browser out of it, but you won't get a web app.

[jgfoot]

On Oct 22, 11:32 am, "Aaron Swartz" <m...@aaronsw.com> wrote:
> Wikipedia says that Digest isn't yet broken but that researchers are
> getting closer to using the collisions to break Digest.

The MD5 reliance is a knock against digest authetication. But it is
still better than nothing. Researchers might be close to breaking
digest authentication, but session cookie authentication was broken
the minute it was invented. SSL is best, if you can afford it, but
for the rest of us digest authentication is an imperfect best choice.

[yejun]

This is a very bad idea. It will cause large amount of unnecessary
data transmitting over the wire.

[jgfoot]

On Oct 22, 7:51 am, "Aaron Swartz" <m...@aaronsw.com> wrote:

> Do you have a demo of the AJAX thing somewhere?

http://www.autopond.com/login-ajax-demo.tar.bz2

Demos a way to let the user enter authentication username and password
without using the browser's default box. (Unless the user gets it
wrong).

[Aaron Swartz]

Neat. The dialog on authentication failure is kind of a bummer, though.

[Kari Hoijarvi]

My take on that:

I work for scientists doing air pollution research. I'm using web.py to
deliver emissions, weather and pollution data to anyone.

In this domain, sessions are obviously totally useless. The data is
public, so there's no authentication. It's read-only, so theres no
state. So I'm in a close to the original static hypertext system, except
I extract subsets of data and format it on the server side. Using
anything else than stateless http-get is pointless.

But sometimes I have to check out data from other organizations. Too
often, their site is an application, which requires several http-post
roundtrips to get what you want. Very difficult to access with scripts,
which is what I do all the time.

So my emphasis here is that tools, like ASP.NET, which make creating an
application with session a breeze, push people too much to create
stateful systems when stateless would be much much better.

Kari

[Hraban Luyat]

> [^w]: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016742.html

>
> The real problem comes when you use cookies to create sessions. For
> example, imagine if Amazon.com just had one URL:

> http://www.amazon.com/ The first time you visited it'd give you the

> front page and a session number (let's say 349382). Then, you'd send
> call back and say "I'm session number 349382 and I want to look at
> books" and it'd send you back the books page. Then you'd say call back
> and say "I'm session number 349382 and I want to search for
> Dostoevsky". And so on.
>
> Crazy as it sounds, a lot of sites work this way (and many more used
> to). For many years, the worst offender was probably a toolkit called
> WebObjects, which most famously runs Apple's Web store. But, after
> years and years, it seems WebObjects might have been fixed. Still, new
> frameworks like Arc and Seaside are springing up to take its place.
> All do it for the same basic reason: they're software for building Web
> apps that want to hide the Web from you. They want to make it so that
> you just write some software normally and it magically becomes a web
> app, without you having to do any of the work of thinking up URLs or
> following REST. Well, you may get an application you can use through a
> browser out of it, but you won't get a web app.
>
> >

Hi Aaron,

RFC 2616: HTTP/1.1, Section 15.6:

> 15.6 Authentication Credentials and Idle Clients
>
> Existing HTTP clients and user agents typically retain authentication
> information indefinitely. HTTP/1.1. does not provide a method for a
> server to direct clients to discard these cached credentials. This is
> a significant defect that requires further extensions to HTTP.
> Circumstances under which credential caching can interfere with the
> application's security model include but are not limited to:
>
> - Clients which have been idle for an extended period following
> which the server might wish to cause the client to reprompt the
> user for credentials.
>
> - Applications which include a session termination indication
> (such as a `logout' or `commit' button on a page) after which
> the server side of the application `knows' that there is no
> further reason for the client to retain the credentials.
>
> This is currently under separate study. There are a number of work-
> arounds to parts of this problem, and we encourage the use of
> password protection in screen savers, idle time-outs, and other
> methods which mitigate the security problems inherent in this
> problem. In particular, user agents which cache credentials are
> encouraged to provide a readily accessible mechanism for discarding
> cached credentials under user control.

(Source: <http://www.ietf.org/rfc/rfc2616.txt>)

That is the reason for HTTP authentication not finding wide deployment.
In my applications, at least. Of course, it doesn't "look pretty", yes,
that's an added problem, but using existing and well-tested mechanisms
like this requires less code and is thus less error-prone. If HTTP/1.1
provided a logout functionality we'd see a whole lot less SQL injection
attacks in login forms. Simply because they wouldn't exist.

I will leave your real point ("web applications should be stateless")
untouched, though :). For today.

Greetings.

[yejun]

From rfc 2617.
http://www.ietf.org/rfc/rfc2617

Digest authentication uses 'stale' to indicate whether client should
require user reenter credential information. It seems to me that
should mean a message of terminating current session.

> > [^w]:http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/0167...

>
> > The real problem comes when you use cookies to create sessions. For
> > example, imagine if Amazon.com just had one URL:

> >http://www.amazon.com/The first time you visited it'd give you the

[Hraban Luyat]

You are entirely right: I stand corrected. What an oddity that they make
no mention of this in RFC 2616... Well, that's that, then. No more pesky
inline login forms for me!

Thanks :)

[yejun]

Obviously 2617 didn't exist when 2616 was written.

> >>>http://www.amazon.com/Thefirst time you visited it'd give you the

[Hraban Luyat]

It's not all that obvious, to me, that they take the trouble to write
about actual plans of developing a fix for this but then, once it is
updated, they do not take the trouble to even write a small note about
it. I mean, it's a really significant topic. Perhaps I'm the only one
who assumed this message to mean "there's just no logout functionality
in HTTP/1.1" (since, after all, this is the HTTP/1.1 standard), but
apparently you have to look through all the other RFCs yourself for
possible updates...?

Anyway, this anti-static-RFC rant is going offtopic :) I guess I should
just read the news more ;)

Greetings

[jgfoot]

On Oct 28, 1:17 pm, Hraban Luyat <bubbl...@gmail.com> wrote:
> It's not all that obvious, to me, that they take the trouble to write
> about actual plans of developing a fix for this but then, once it is
> updated, they do not take the trouble to even write a small note about
> it. I mean, it's a really significant topic. Perhaps I'm the only one
> who assumed this message to mean "there's just no logout functionality
> in HTTP/1.1" (since, after all, this is the HTTP/1.1 standard), but
> apparently you have to look through all the other RFCs yourself for
> possible updates...?

Technically speaking the purpose of "stale" is to require the client
to use a new nonce value. My digest authentication code does this (I
think) every 3 minutes, on the theory that future modern processors
will take at least that long to brute force.

You can also use "stale" to force the client to start using a new
nonce, and then have the server treat that nonce as invalid. My code
also does this. "Good" nonces are 34 random characters; "bad" are 32
random characters. When you logout, it changes your nonce to 32
characters. Then, it never accepts 32 character nonces.

RFC 2617 mentions stale, but never mentions this "logout" use of it.
That's unfortunate, because clearly not all implementers of digest
authentication on the server side have thought of it (judging by
sample code I saw during my research).

[yejun]

stale=true means new nonce. stale=false means new user interactive
login required.

[9exbizy]

Hello Aaron,

How can I get this to read?

I am trying to retrieve sensor data(they are in rdf triples) for user display in JSON format using web.py for the web service.

Regards