|
.net
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Going sessionless (and cookie limitations)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 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 Show quote "Jon Davis" <j**@REMOVE.ME.PLEASE.jondavis.net> wrote in message news:OQskaJZ1GHA.2036@TK2MSFTNGP05.phx.gbl... > 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 > 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/ Jon Davis wrote: Show quote > 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 Hi, Jon.
re: > I just got hired by a company that told me their web site is sessionless to cut down on the Ask them whether they prefer a bit of overhead...or a safe server.> overhead of using SQL Server or a state server to host session state information. 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/ =================================== Show quote "Jon Davis" <j**@REMOVE.ME.PLEASE.jondavis.net> wrote in message news:OQskaJZ1GHA.2036@TK2MSFTNGP05.phx.gbl... > 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 >  |
|||||||||||||||||||||||
Other interesting topics