Going sessionless (and cookie limitations)

[Jon Davis]

Does anyone know of a best practices or common practices article URL for
implementing a sessionless web farm while still managing user logins, etc.?

I just got hired by a company that told me their web site is sessionless to
cut down on the overhead of using SQL Server or a state server to host
session state information. I've been scratching my head to try to figure out
what the ramifications are, and what methodologies could be used to retain
common functionality such as user login support without imposing a security
risk.

I'm assuming cookies are used for the entire "session" but then my question
becomes what limitations still exist for cookies? Don't they support only a
very, VERY small name/value size and a very small record count?

Jon

 

[Grant Merwitz]

I don't believe cookies are limited to miniscule data.
In the same respect i wouldn't keep large datasets in there either.
Rather use a unique user id that can retrieve info from the database.

Regarding security just ensure your cookie is properly encrypted,
and expires in a timely manner.

HTH

 

[Brennan Stehling]

I think you end up spending a great deal more time in solving the
cookieless problem than you would if you use a load balancer which
maintained sticky sessions.

The sticky sessions will ensure the same web user reaches the same
server in the web farm so the reconnect with the same session. You
will not have to deal with additional database load because your
sessions are local to each machine in the web farm, not shared with a
central database.

Most decent load balancer hardware supports sticky sessions.

After attempting force ASP.NET applications like survive in a
cookieless mode, I learned it is best to avoid it whenever possible.

Brennan Stehling
http://brennan.offwhite.net/blog/

 

[Juan T. Llibre]

Hi, Jon.

re:

I just got hired by a company that told me their web site is sessionless to cut down on the
overhead of using SQL Server or a state server to host session state information.

Ask them whether they prefer a bit of overhead...or a safe server.

Print out, or point them to, this article by Dino Esposito:
http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/cookieless.asp

Really, using State Server doesn't qualify as a lot of "overhead",
considering what State Server does for a web farm.

SQL Server might be overhead (considering what it costs)
but State Server is free, and doesn't require gobs of server resources.

Read the article/download the code by Jeff Prosise. It's a security eye-opener:
http://msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/default.aspx
His SecureSessionModule foils most session hijacking attempts.




Juan T. Llibre, asp.net MVP
aspnetfaq.com : http://www.aspnetfaq.com/
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================

 

[Jon Davis]

Thank you, Juan, for providing links to articles which is what I asked for.

Guys, one question and concern that remains is that it was explained to me
that the benefit of using cookies to host all session information rather
than using the ASP.NET session object to store state information was to
eliminate the traffic going from the web servers to the state server or SQL
Server. Is it just me or is this conclusion littered with fallacies? Don't
all cookies get sent with every web page hit--indeed, with every HTTP
request for every object on the same host/domain, including images and
scripts? Doesn't that mean that a cookie-based solution imposes the same
network hit, only instead of spawning network overhead behind the firewall
on the LAN, you're imposing the network overhead on each HTTP request over
the Internet, multiplied by the number of objects loaded from the same
host/domain?

So in other words, couldn't the bandwidth issue on the server side be
alleviated by purchasing some 10GB/s Ethernet cards and a 10GB switch? Then
as far as memory is concerned, why not just install a 64-bit operating
system on 64-bit hardware with, say, 16GB of RAM or more, and multiple Xeon
multi-core processors?

There is just so much one takes for granted in a Session-based server
environment, I'm not sure what the caveats are, but more so I'm not sure
what the point was.

- Jon

 

[Joerg Jooss]

Thus wrote Jon,

Thank you, Juan, for providing links to articles which is what I asked
for.

Guys, one question and concern that remains is that it was explained
to me that the benefit of using cookies to host all session
information rather than using the ASP.NET session object to store
state information was to eliminate the traffic going from the web
servers to the state server or SQL Server. Is it just me or is this
conclusion littered with fallacies? Don't all cookies get sent with
every web page hit--indeed, with every HTTP request for every object
on the same host/domain, including images and scripts? Doesn't that
mean that a cookie-based solution imposes the same network hit, only
instead of spawning network overhead behind the firewall on the LAN,
you're imposing the network overhead on each HTTP request over the
Internet, multiplied by the number of objects loaded from the same
host/domain?

No, you're confusing spending extra bandwidth (for cookies) with adding another
network hit in your LAN.

Cookies are just part of your usual request/response exchange and simply
inflate a request's or response's size by up to 4 kB per cookie. Accessing
a state server means leaving process boundaries, hitting the network, marshalling
data, etc. A normal page that uses session state will actually access the
database *twice* -- to acquire session state and write it back after processing.


If you're setting the EnableSessionState attribute in a page directive to
readonly or false, you can reduce or eliminate these extra hits on the state
server, but of course this limits your access to session state in such a
page as well.

Cheers,