Is a Session-Less Design feasible?_问答_开发者

Just brainstorming some ideas for a Web App I'm building soon.

One of the cornerstones of the Web is Session Handling: Have the user log in, send a cookie with magic binary encoded pixie dust, trust the user blindly afterwards.

I just wonder if it's feasible to completely eliminate 'traditional' sessions for a web app that would normally use it, e.g. an online store.

The idea would be to have a 'server side session' that doesn't use the SessionID or anything, but the username instead. So there is exactly 1 session per user, not more. That would allow stuff like a persistent shopping cart to work.

Authentication would be handled similar to how Web Services work: Expect HTTP Digest authentication on every single page view.

Ignoring the fact that anonymous visitors would have to be handled differently, do you think this approach would be feasible? Or would the additi开发者_运维百科onal traffic/load for constant authentication be a deal-breaker in the long run?

First off, we don't use sessions at all.

We found that utilizing session complicated the code without any benefit. There are only two reasons to even consider using session state. The first is to reduce the amount of traffic to your sql server.. However, with load balanced web servers etc, session has to be stored in a sql server... Which kind of eliminates it's first point. But it's worse than that as the session has to be retrieved, deserialized, serialized, and stored on every single page load.

The second reason is to keep from having the browser pass the user id back to the application on each request. However, "session hijacking" is a fairly easy trick to pull off and is rarely taken into account.

So, instead, we use a highly encrypted cookie with non-guessable values that indicate exactly who the user is. We've coupled this with a changing, non-guessable, request id and have eliminated both session state (and it's unnecessary overhead) while at the same time improving security all around.

Can the cookie be stolen? Sure, but it has a very limited life that is the amount of time between two postbacks. Which means it will be found to have been compromised rather quickly.

So, I wouldn't say sessions are a "corner stone" of the web. Rather I'd say they are crutches that are often used improperly and should be avoided for both security and performance reasons.

All of that said, the only way you are going to tie this to a user id is if you force your users to login/create account prior to shopping.. Which no one is going to do unless they have no other choice but to be on your site.

Oh, and don't take my word for it:

4GuysFromRolla.com -> Session variables are evil.
aps.net -> Are session variables still evil?
Scott Hansleman -> Moving Viewstate to Session Pay attention to the part in bold covering memory consumption and it's ability to stay around for way too long.
Coding Horror -> Your Session has timed out This details just some of the problems associated with even using session
Wikipedia -> Session Hijacking What list would be complete without a link to wikipedia?

REST-like implementations such ASP.NET MVC do not require session state at all.

You should just use sessions. Even if its your own session implementation: eg. cookie contains random key used to store information the server. A cookie must be used or you will have to encode all links on the site with a query parameter that specifies the key -- bad idea!

I would then store the "session key", or what every you want to call it, with the persons username in the database.

When a user logs in to your site simply restore their previous "session".

Other then the query parameter option, which is a bad idea, you can track users by IP address. But this again is a horrible idea! Eg. many buildings have a limited number of Internet IPs and many times more internal computers.

There is no good way to track a user without using cookies.

Yes maybe you can use HTTP authentication but why bother? You are just going to introduce new issues and put limitations on your UI.

That actually is pretty much what a traditional session does -- provide a unique identifier to distinguish a browser "session", all you are doing is tying it to username rather then a random variable.

I would say just be very careful of how you generate your token, if it is reproducible you could easily accomplishes the goal of a session fixation attack by generating someone elses session and jamming it into a cookie. That is the reason that sessions are usually a random unique value.

The idea would be to have a 'server side session' that doesn't use the SessionID or anything, but the username instead. So there is exactly 1 session per user, not more. That would allow stuff like a persistent shopping cart to work.

That's just a session, but using the username as the session identifier - which is going to cause all sorts of problems - its open to replay attacks even if you encrypt it. You can't change the encrpytion per-request because that will break when the user opens a second window or presses the back button.

You can't rely on the client address - multiple users may share a NAT address, the same user may access your site from behind a cluster of load-balanced proxies.

like a persistent shopping cart

...implies that you have server-side data for the customer - since the size of this data will vary, you can't store it in the URL nor in a cookie.

Expect HTTP Digest authentication on every single page view.

That presupposes that you create accounts for every user, and that you're not concerned about the impact of the same user id being used by different clients. I don't think that this would require significantly more processing than a conventional session - but its still web-based session management with a different set of problems and vulnerabilities compared to the conventional approach.