This has haunted me a few times in the past, so for my own sake I figured I would write a quick blog that I can reference in the future. Hopefully others find it valuable as well.
I ran into an issue today where the forms authentication timeout didn't seem to be taking affect. This isn't the first time that I spent more time that I care to admit troubleshooting the issue. For some reason, no matter how hard I tried, I couldn't remember the exact details of the previous times, so I started fresh again today.
I even tested the timeout at 1 minute, like so:
<forms name=".ASPXAUTH" loginUrl="Login.aspx" protection="All" timeout="1" path="/" slidingExpiration="true">
I could log in and wait for 5 minutes without touching the page, but when I refreshed the page, I was still logged in. At this point I realized that the timeout value wasn't working at all. When I left the page untouched for 35 minutes, I would be logged off.
As a web host, we continually get the opportunity to troubleshoot other people's sites and code. Today's was the same situation. It wasn't code that I wrote, but rather that of one of our clients at ORCS Web.
I checked the docs, confirmed again that the timeout property is minutes and not seconds. (I did know this well but when things don't work, even simple things need to be double checked), and I checked the syntax of the rest of the tag. I also changed other things in web.config to break the site to confirm that web.config was actually being used. I call this the 'break' test.
I googled it and found a number of people with the same error, but after reading post after post I wasn't any closer to figuring it out except that the trend seemed to suggest that it wasn't the syntax of the tag that was at fault, but rather some other code related issue.
Sure enough, I finally decided to take a closer look at the code, which fortunately was available to me, and I found that the developer had overwritten the default authentication and instanced his own FormsAuthenticationTicket. This overrode the web.config settings rendering them useless. I uncovered the following:
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket
1, // version
txtEmail.Text, // name
DateTime.Now, // issueDate
DateTime.Now.AddMinutes(30), // expiration
false, // isPersistent
roles, // userData
FormsAuthentication.FormsCookiePath // cookiePath
The web.config settings work as advertised unless they are explicitly overwritten from code.
The web.config settings aren't used unless the default authentication is used or the developer specifically uses it. This is a reminder to myself because now that I think about it I remember that previous issues like this always resulted in code changes. They weren't a result of the web.config settings. Note to myself: When troubleshooting forms auth timeout issues, blame code earlier in the troubleshooting, chances are good that the web.config settings were fine all along.
Here are a few tips that I discovered or was reminded of today:
- The slidingExpiration property defaults to True in .NET 1.x has been changed to False now in .NET 2.0
- Here's a link to the documentation for the Forms Element: http://msdn2.microsoft.com/en-us/library/1d3t3c61.aspx
- The IIS session timeout and the ASP.NET <sessionState> tag don't have any affect on the forms authentication timeout.
- Scott Hanselman, in his story telling way, gives a way to read the web.config forms timeout value from code: http://www.hanselman.com/blog/AccessingTheASPNETFormsAuthenticationTimeoutValue.aspx
- ASP.NET v2.0 used the timeout value in that property for the *persistent* authentication cookies. This is important to take note of. Dan Sellers explains it a bit more here: http://blogs.msdn.com/dansellers/archive/2006/02/15/532359.aspx