Forms Authentication Timeout

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:

<authentication mode="Forms">
   <forms name=".ASPXAUTH" loginUrl="Login.aspx" protection="All" timeout="1" path="/" slidingExpiration="true">
   </forms>
</authentication>

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.

Solution

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
 );

Conclusion

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. 

Misc tips

Here are a few tips that I discovered or was reminded of today:

 

15 Comments

  • Scott,
    You might like this one... Can I recommend that developers who are developing on a local machine and then uploading to a server make sure that the authentication cookie has a different name in each web.config! I just could not figure why I was getting such odd results.
    Many thanks for your blog, it really helped - funny the way the mind works.
    I am using the new login in controls in 2.0 btw.

  • thanks for the hint. this just happened to me and i never thought to check my code. i feel so stupid

  • Thanks, your article helped me solve the problem, a hard-coded value buried in a business library.

  • Hi Scott, I had a similar problem and used the standard login page. Thus the values in web.config were obeyed. I set the timeout to 86400 (2 months), but still I was kicked to the login page after 5 minutes of inactivity. I checked the ".ASPXAUTH" and it was there and the expiration set to 2 months in the future... so I tested it again on my local IIS and there it worked. So I concluded that the hosting did something to save memory as you say in your article. In fact they answered me: "i did just increase the IIS application pool idle timeout limit from 5 up to 60 (max.) minutes." now it seems to work. I'll wait for more than one hour to see what happens and let you know the results... cheers

  • Hi Paolo,

    Thanks for the update on your situation. I bet the machineKey is coming into play too. What happens if you set a static machineKey? If you do that then even if the app pool recycles then it will still allow them to log in again with the same session cookie. Changing the idle timeout to 60 will help a lot. 5 minutes was way too low, so now it should keep all sessions open for 60 minutes from the last activity which will also keep a session for up to 60 minutes (even with a dynamic machineKey).

  • Hei Scott, now I'm in a better situation but still I'm not satisfied. No need to re-login for 60 minutes, but still I want the user to stay logged in for 2 months. The "remember me" login feature is quite a standard in all usable forums and modern websites and I want it! It's annoying for a user to login each time he comes back (unless before one hour, which won't be the case for the majority).

    The situation seems quite stupid: the cookie is set but the sessions are deleted after 1 hour. So as result when I come back to the site after 61 minutes, I have to login again, even if the cookie is set to expire 2 months in the future. So should I, as workaround/fix, code myself a cookie check and re-create a session if the cookie is valid? I guess that for the security point of view this won't be a good idea (unless the cookie is encrypted, but then I wonder if I can decrypt and check it programmatically, I have to check...)... Anyway tat should be "out of the box" with asp.net forms authentication, I wonder why I have such a stupid problem: if I have to code such things myself then I could have created my authentication system from scratch and not use this standard... What can I ask the host, I don't think they will increase the IIS idle timeout to 2 months just for me...

  • Hi Paolo,

    Two things I should test are:
    - Visit the page, log in, click remember me. Then come back in 30 minutes and refresh the page. Then test again at the 65 minute mark. Does it remember you? If so then it has to do with the idle pause and you should be able to fix this by adding a static machineKey setting in your web.config.
    - After logging in and clicking remember me, can you close your browser, open it, and log in without it asking for you to log in again? That will confirm that you are getting a persistent cookie correctly.

  • Another option would be to programmatically set the timeout from the value specified in the web.config:

    FormsAuthenticationTicket ticket = new FormsAuthenticationTicket
    (
    1, // version
    txtEmail.Text, // name
    DateTime.Now, // issueDate
    DateTime.Now.Add(FormsAuthentication.Timeout), // expiration
    false, // isPersistent
    roles, // userData
    FormsAuthentication.FormsCookiePath // cookiePath
    );

  • Good idea. Thanks James for the code example.

  • Thanks for posting this - It's been ages since I had to deal with a new site and the timeout value, and this was exactly what I needed.

  • Hi Avi,

    I haven't run into this specifically, and doing a google search on that exact phrase doesn't turn up anything except for your stackoverflow post. So it sounds like it's specific to your MVC site.

    My guess is that your site has various parts to it and a JavaScript call is failing after the timeout. The best way to track it down would be to break the page into smaller parts to determine which part is failing. For example, can you turn off any JavaScript (jQuery, etc) that is used on that page and confirm that it doesn't throw those exceptions anymore.

    Once you've tracked it down, you should be able to handle the JavaScript call to ignore a missing or empty HTML Container.

  • on async postback the cookies expier in the timout mentioned rather then sliding effect.

    I do a async postback which casuses the auth cookie to expire in the timeout mentioned instead of considering the sliding effect, the same does not happen when a referesh is performed or a redirect is performed, sliding takes effect.

    Also if i do a postback after adding trigger it is working.

    If I add trigger for it i.e. not to do a asyncpost back then it is working but I want asyncpostback

  • Brilliant, thanks for posting this. I just had the same problem, and I can't even blame someone else as it was my own code ;)

    As an update, the linked Scott Hanselman article is a bit out of date now. As of .Net 2.0 you can get the config value from FormsAuthentication.Timeout.TotalMinutes.

  • Thanks Varangian for mentioning the update.

  • Hi Manpreet. Yes, if it works then it sounds like you have a winner. My issue was that it was overwritten in code, but for most cases web.config is the best place to set this.

Comments have been disabled for this content.