ASP.NET Login is lost when I refresh the page. How come?

Here another interesting problem. Crazy logins loosing their tokens. I had a chat with a friend that happens to work in an online shop website. He knew that I've developed once the authentication/authorisation mechanism for a similar company then he asked me that:

Edge, my ASP.NET website was running fine using SQLExpress 2005. My development and test environments are fine and my tests look OK, but since I moved my website to a better host using SQL Server 2005 I keep getting complaints from my customers; they say all of sudden while navigating the website they get logged out and because of that they are forced to login again. Just like that, out of nowhere. They say they can even add items to the shopping cart but when they start navigating  the catalog somehow they realize they are not logged in anymore. That's causing me a lot of stress because ultimately I am loosing revenue. So I am suspecting that it could be some page that is forcing them to logout or doing some crazy redirect. I don't know.

But wait, there is more. Some customers say that after they are logged out, they wait a few minutes and then they refresh the page. They say this will bring their login back (???) Tha's crazy. How come they are logged in my website, then they get kicked out, then a few minutes later they are automatically logged back in? The only new variable is the SQL Server 2005. Is this a MS SQL Server 2005 bug?

My dear friends, I completely understand this case and I know the pain to debug and trace such a environment. Sometimes these problems can drives us crazy during long weekend nights.

So here a little diagram for us to start our case study:

So his environment is a ASP.NET website setup on a web farm, running IIS and having as backend a single instance of SQL Server 2005. The users were able to login to the website but then after a page refresh, that could not be determined for sure when or where, they get logged out. According to him, the only new variable was the setup of a new SQL Server, since before he was running using SQL Express; Interesting to note here: you might be surprised to see how many people actually can use SQLExpress as their backend. Based on that, I had a feeling that it was not going to be a code issue, but most likely a setup or environment issue.

I noted that he heavily uses ASP.NET Sessions tables for his product. So, this gave me a good clue for us to look at the problem.

For those who don't believe me, ASP.NET session state really works  flawlessly on web farms. If you have one and are not using it, I would say : give it a go. And I would go even further, use a database to store the session state. It does not have to be SQL Server database, it can be a MySQL, for example. I highly recommend MS database anyway. Why? Because if you use SQL Server  you can replicate the database and it is going to integrate beautifully with you ASP.NET application.  Try to do this using any other database and you are in big trouble. (Or not, if you don't like weekends with the family anyway). Now add to this the amazing caching capabilities provided by SQL Server 2005. My friend, you are set for a very stable environment.

His host provider uses ASP.NET session in a web farm and a load balancer. Now we saw a likely breaking point. Did he setup correctly the web.config file for the new environment? Did he make sure all the servers were running the required service for state server? Ultimately, of course, we should rely in the hosting company to do this for us, but double-check just in case before doing any release like this one.

So, in my head I pictured this: The user was going back and forth, loosing and getting back his login token. Like if every time he did a refresh, his request would be transferred to another server which did not have the state server running, therefore no information about his login.

Then he refreshed again at some point, his request was redirected to a machine with the state server running, and the login was back again.

We tried this. Double-checked if the web.config was correct for state servers and we made sure that every server in the farm had the service on. The infra-guy fixed those and voilla…back in business.

Hopefully this was the solution. So far, so good.

See ya later.