Forms Authentication timeout default in ASP.NET 2.0

49 Comments

• Scott,
  
  
  
  One thing that I have struggled with in 1.1 is that the Authentication timeout and the Session timeout are [seem to be] separate. Also, it seems that the algorithms in which they are updated are different.
  
  
  
  For example, with Auth it seems that the expire time is not updated each time you make a request, but only if you make a request where you have less than about 50% of your timeout remaining. Where as it seems that session expire time updates on each request giving you another X (configured) minutes each time.
  
  
  
  Due to this I have run into issues where a user was still authenticated but their session had timed out which caused exceptions in our app.
  
  
  
  Generally I handle this in my login page by setting an Auth timeout that is 3 minutes less than the session timeout. Since I do this if the customer changes the session timeout they are also changing the Auth timeout.
  
  
  
  So, can you explain why the timeouts are [have to be] separate and why they don't extend/update in the same way? Also, has there been any change to this situation in 2.0?
  
  
  
  Thanks,
  
  BOb
  
  
  
  

• Scott,
  
  
  
  The 1.1 docs for the timeout attribute state:
  
  
  
  "Specifies the amount of time, in integer minutes, after which the cookie expires. The default value is 30. If the SlidingExpiration attribute is true, the timeout attribute is a sliding value, expiring at the specified number of minutes after the time the last request was received. To prevent compromised performance, and to avoid multiple browser warnings for users that have cookie warnings turned on, the cookie is updated when more than half the specified time has elapsed. This might result in a loss of precision. Persistent cookies do not time out."
  
  
  
  Above you say in 2.0 the value has been changed to be 30 minutes by default. So, how is that different than 1.1?
  
  
  
  Thanks,
  
  BOb
  
  

• the feature of the clock being reset only when idle, is it also valid for ASP.NET 1.1?
  

• Hi Bob,
  
  
  
  The difference from V1.1 is that we now use that value to set both the persistant and non-persistant setting (previously it was only used for the non-persistant case). Previously, the persistant duration was just hard-coded to a really long time (I think 50 years).
  
  
  
  Hope this helps,
  
  
  
  Scott
  

• You mention: "everytime they hit the site the 30 minute window clock gets reset"
  
  
  
  However looking at RenewTicketIfOld using Reflector, it only issues the new ticket if the time from the issue date is greater than the time until the expiration date (which is the same behavior as in 1.1).
  

• I guess I don't understand, how can a persistent cookie timeout in 30 minutes? Doesn't seem very persistent?
  
  
  
  So, it lives beyond when the browser is closed, but still times out in 30 minutes?
  
  
  
  Also, I don't see my other comment here about the differene bettween the session timeout update and auth timeout update. Did you not get that question?
  
  
  
  BOb
  
  

• Hi Bob,
  
  
  
  Session and Authentication timeouts can be configured separately because often times you want session state to be much shorter than authentication in duration. For example, a portal page might want a user to be able to authenticate and not have to login every-time they go to the site (this is where persistent cookies come in handy), but use sesssion state to cache some settings each time they are active on the site.
  
  
  
  Hope this helps,
  
  
  
  Scott
  

• I think what Bob is asking is, what is a good way to deal with that issue. I have the same problem. After authentication, I set a session variable of the logged in user id. I use that to load all the specific data. But when the session expires prior to the authentication, the user is logged in, but the app no longer knows who they are.
  

• I'm having an issue with Forms Authentication. Here's what I' doing that doesn't make sense:
  
  1) Login to a site
  
  2) close the browser
  
  3) start a new browser and go to the site
  
  
  
  I would expect it would make me login again, but it isn't. I thought that each independently started browser (not file new or cntr-n) created a new session? What am I not understanding?
  

• Hi Drew,
  
  
  
  It depends on how you configure the forms-ticket as to what the behavior you will see.
  
  
  
  The second param to FormsAuthentication.SetAuthCookie indicates whether the browser should save the cookie persistently (in which case you'll get the behavior you are seeing where it survives browser restarts), or just let it expire when the browser shuts down.
  
  
  
  So:
  
  
  
  FormsAuthentication.SetAuthCookie("scottgu",
  
  true);
  
  
  
  will cause the cookie to persist, while:
  
  
  
  FormsAuthentication.SetAuthCookie("scottgu", false);
  
  
  
  will force a new login everytime the browser restarts.
  
  
  
  Hope this helps,
  
  
  
  Scott
  

• Hi Matt,
  
  
  
  What I recommend doing in that case is checking to see if the user is authenticated in the Session_Start event -- and if so then re-populating the session object using that event. That would allow you to have one place in the entire app that re-populates the session when things time-out.
  
  
  
  Hope this helps,
  
  
  
  Scott
  

• Hi Bernhard,
  
  Can you send me email with more details about your application (as well as the web.config file itself)? I can then try and help figure out what is going on.
  
  Thanks,
  
  Scott
  

• Hi,
  Is it possible to have different timeout periods for different roles?
  Failing that, would it be possible to have a different timeout period for a single page of the project?
  
  Many Thanks
  Matt
  

• Hi Scott,
  
  How can I trap an particualr session. If either an application crash or system reboot in between of running application.
  

• Hi Matt,
  
  Unfortunately I don't think there is an easy way to have separate expiration periods based on the role. In theory you could write an HttpModule that intercepted and manipulated this - although frankly it would be pretty tricky logic and I'd probably recommend against doing this.
  
  Sorry!
  
  Scott
  

• Re: "The difference from V1.1 is that we now use that value to set both the persistant and non-persistant setting (previously it was only used for the non-persistant case). Previously, the persistant duration was just hard-coded to a really long time (I think 50 years)."
  
  I do not understand why the same value is used for both the persistent and non-persistent cases. Isn't that two different things? If the user checks RememberMe, then I want them remembered for a long time. I can adjust that with the timeout value. However, if the user does NOT check RememberMe, then I want them forgotten when when their user session expires, not just when they close the browser.
  

• Hi Patrick,
  
  In general code always trumps configuration settings. So if you set it via code it should override the web.config value.
  
  Hope this helps,
  
  Scott
  

• Scott - Why couldn't you set different timeout values for different roles? You can specify the timeout for a FormsAuthenticationTicket when you create it, so you could specify a different timeout value for different roles. Unfortunately, the timeout value in the web.config seems to override whatever timeout I specify in the FormsAuthenticationTicket constructor.
  

• Hi Michael,
  
  You can control the timeouts for Role cookie caching and Forms Authentication cookie timeouts separately.
  
  What I typically recommend is to set the FormsAuth ticket timeframe to be a large value, and then keep the Roles ticket small (only a few minutes at most).
  
  That way if you want to change someone's role permissions, you can quickly do so have it immediately take affect.
  
  Hope this helps,
  
  Scott
  

• Hi Evan,
  
  Did you set this value in your local web.config file? If so, it should be used when you update the remote server.
  
  Thanks,
  
  Scott
  

• I did set it in my local web.config, and I upload that file to the remote host. I know that web.config is uploaded because it controls several other aspects of my website, which work fine on the web host.
  

• Hi Scott,
  
  I just wonder that what the first version of ASP.NET Ajax resolved the problem of "Unknown error" pop up after updatepanel postbacked and session expired. I would like to check my version.
  

• Hi Evan:
  
  I, too, am having the problem of persistent cookie expiring after 30 minutes (or however many minutes I set in the application's web.config file).
  
  When user logged in, I used the following codes to change the expiry date of the cookie:
  
  If Membership.ValidateUser(TxtID.Text, TxtPW.Text) Then
  
  Dim cookie As HttpCookie = FormsAuthentication.GetAuthCookie(TxtID.Text, ChkRememberMe.Checked)
  
  cookie.Expires = DateTime.Now.Add(New TimeSpan(90, 0, 0, 0))
  
  . . .
  
  So in theroy, the application should remember me for 90 days. But no. 30 minutes of inactivity and I'm asked to log in again. It is also driving me crazy. . .
  
  
  

• Hi Justin,
  
  Can you show me what settings you have in your web.config file? If you email them to me I can take a look and help you get them fixed.
  
  Thanks,
  
  Scott
  

• Hi Justin,
  
  The problem you are having above is that you have the timeout attribute set to 30 - which is why the cookie is timing out in 30 minutes.
  
  If you set this to 129600 it will change it to 90 days.
  
  Thanks,
  
  Scott
  

• Hi Scott,
  
  My web.config file is as follows :
  
  
  
  and my global.asax is as follows:
  
  Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
  ' Fires when the application is started
  Server.ScriptTimeout = 900
  ........
  End Sub
  
  The applications authenticates a user's login based on the user id which is one of the session variable. When this session variable becomes empty or when abandoned, the user is logged out.
  
  I understand that the session variables become empty on time out.
  
  Based on which time out value does the session variable become empty. Is it from Global.asax or Web.config.
  
  Also, i understand that time out in web.config overrides the IIS timeout.
  
  Please respond asap
  

• Doesn't the timeout=30 value in Justin's web.config set the timeout for the *ticket* that is contained in the cookie? If the ticket expires before the cookie, then the cookie is no longer valid, correct?
  
  So, if I understand correctly, then Justin could programmatically create a ticket with the 90 day timeout and add that into his cookie.
  
  

• Hi Scott,
  
  When you programmatically set the cookie timeout like Justin did above the first time, it will be set to 90 days as he specified.
  
  The problem is that the window is a sliding window - meaning everytime you visit the site it gets extended again. The problem above is that his web.config file is still set to 30 minutes - which means on the next visit to the site it will be reset to 30 minutes from then.
  
  The right way to fix it is to modify the web.config file.
  
  Hope this helps,
  
  Scott
  

• Hi Scott,
  You stated on 11/10/06: Session and Authentication timeouts can be configured separately ...
  how?
  I have the timeout set to 30 days in the web.config (for persistent cookies), but it would be nice to force a login if a user leaves their browser open over nite.
  thanks
  

• Hi Doug,
  
  If you want to force a user to re-login if they leave the session open over night, I'd recommend setting the timeout to be more along the lines of a few hours. Note that the timeout is sliding - so as long as they keep visiting the app the timeout will reset (for example: if the timeout is 4 hours, then every time they hit the site it will be reset to timeout in 4 hours if there is no more activity).
  
  Hope this helps,
  
  Scott
  

• Hi Scott,
  But then the 'remember me' wouldn't really be remembering for a long time, right?
  
  My question is the same as Casey's issue of October 10, 2006 5:07 PM. How to have 'remember me' last a month or year, and have an unused open browser time out in 30 minutes?
  
  thanks again
  

• Hi Doug,
  
  It is a little odd to have the remember me remember for a month, but have an open browser time out after 30 minutes. Because a user could just open a new browser window and it would be logged in (since you remembered it for a month).
  
  What you could do, though, would be to issue another temporary cookie manually yourself within the application_authenticate event in global.asax. You could then check whether this value existed, and if so whether it was more than 30 minutes old. If it was, then you could assume the user left the browser window open and take whatever action you wanted.
  
  Hope this helps,
  
  Scott
  

• Scott, Thanks for that recommendation.
  
  Sorry I'm not explaining my question very well, but I'll give it 1 more try, just to make sure the solution matches the question.
  
  A persistent cookie is set to 1 year in web.config:
  
  
  
  
  A user logs in without checking the 'remember me' box. As long as they don't close their browser, they will not time out for a year.
  
  In this situation, how can the user be forced to log in again after 30 minutes of non-use?
  
  

• Hi Doug,
  
  For this scenario I think you'll want to use the temporary cookie approach I mentioned above.
  
  Sorry for not having a better answer!
  
  Scott
  

• 
  can you help me to create a user session variable in asp.net 2. i have done this task asp.net 1.1 but in asp.net 2 it something different from that.
  

• Hi Scott,
  I'm really paranoid about the fact that asp.net 2 is using membership, roles and provider models but the only way to really use this is to use their database schemas which installs a database with tables liks aspnet_users, etc. To get around this I'm doing my own forms authentication using FormsAuthentication.SetAuthCookie then I'm setting session 3 session variables to hold user info such as userid, name. I know the profile model does this but I'm not using this method as we have user tables already built. I used your tip from an earlier post about using Session_Start to check for session timeouts and repopulate the session, which works fine. But now I have two questions:
  
  1) Is using session variables the best (based on security) method for holding user information.
  2) I have a web service in the website which I'm using to do XMLHTTP posts ie. ajax. How secure is this under forms authentication. I've read that forms auth is not the best method for securing web services but since its only consumed by users of the website it should be fairly secure, right?
  
  thanks in advance
  

• Hi Simon,
  
  In general I'd strongly recommend using the built-in authentication support system - since it has been really tested and security probed hard.
  
  If you want to change the schema and not have the tables called aspnet_ you can register an alternative Membership/Role/Profile provider - this will then allow you to have the schema be whatever you want.
  
  This blog post links to some good providers that ship with full source and are easy to adapt: http://weblogs.asp.net/scottgu/archive/2006/10/13/Tip_2F00_Trick_3A00_-Source_2F00_Documentation-for-Simple-ASP.NET-2.0-SQL-Providers-Published.aspx
  
  You might want to spend sometime looking at these to see if you could use these (or at least start with them) for your project.
  
  Thanks,
  
  Scott
  

• Ok, I read most of the q&a's above, but did not see the answer to my question which is this:
  
  I do not have a persistent cookie.
  I have a session timeout of 120 mins.
  I have a forms authentication session of 120 mins.
  
  You said: everytime they hit the site the 30 minute window clock gets reset -- so it is only if they are idle that it will timeout
  
  I want the person to stay logged in as long as they are using the site, however after 120 mins of inactivity, prompt for logging in again.
  
  Therefore, how is the forms authentication session length reset/extended? Is it when a person is using ANY page of the site (within the 120 min time period)? Is it only when they login and at 120 mins (regardless of activity) it logs you out (doubt it but have to ask)? Or do/can you write code to check/reset/extend the session (such as Context.User.Identity.IsAuthenticated, etc)?
  
  I have a problem where people are being timed out and this is being explored, along with other possibilities, in order to find out exactly what is going on.
  
  Also, is there a way of being able to see the value of the session length? I would prefer in any environment being able to see the numerical minute value, but I can handle seeing it only in debug mode as well.
  
  I know that is a lot... but any help is appreciated
  Thanks!
  - Glenda
  

• Hi Scott,
  
  Is there anyway to capture the forms timeout event in a page?
  
  Here's the scenario: There's a main page with a bunch of data records (parent window). You click on a record and it opens a new browser window (child window) where the user can edit/update data and then save the record (which closes the window).
  
  In some cases a timeout will occur before the record is saved. In such a case, the window redirects to the login page. This is fine for the parent window but for the child window I'd like it to just display a message that it has timed out.
  
  I've tried to set breakpoints in the child window in all the "page events" (e.g. preinit, init, etc) but none of them get hit.
  
  Is there a way to do what I'm trying to do?
  
  Thanks in advance.
  Mark
  

• Hi Mark,
  
  Unfortunately there isn't any easy way to check this I'm afraid. The one possibility you might want to consider would be to do an AJAX callback from JavaScript when you go to close the child window. If it is redirected to login.aspx then you'd know the timeout has happened.
  
  Hope this helps,
  
  Scott
  

• Hi KP,
  
  Unfortunately when a client-side redirect happens the browser does a GET based redirect - which means that the form field data is lost.
  
  Sorry!
  
  Scott
  

• Question...
  
  If you set the timeout in your login page, will the timeout in the web.config override this value? I'm going to guess it's the default used, unless otherwise set in the auth ticket.
  
  Thanks!!!
  
  
  Example (login.aspx.cs):
  FormsAuthenticationTicket fat = new FormsAuthenticationTicket(1,
  email.Text, DateTime.Now,
  DateTime.Now.AddDays(7), RememberCheckbox.Checked, strRole,
  FormsAuthentication.FormsCookiePath);
  
  Example (web.config):
  
  
  
  
  

• Hi Mike,
  
  Any chance you could send me an email with this question? I can then loop you in with someone on the team who can confirm for sure.
  
  Thanks,
  
  Scott
  

• Hi Zachary,
  
  I believe what will happen is that on each visit to the web-site, the formsauth ticket will be renewed. The renewal window will end up being picked up from the web.config file - which will effectively replace what you specified in code.
  
  Hope this helps,
  
  Scott
  

• Thanks Scott. The email is on its way to you.
  
  Mike
  

• Hi Scott,
  I'm using ASP.Net 1.1.
  My website is using Forms Authentication but we set our own AuthCookies and specify the Application_AuthenticateRequest.
  
  When a user logs in with user id AAA in session 1 and user id BBB in session 2, both sessions share the AuthCookie created last because they have the same name. Some admin users like to view a couple of user's accounts simultaneously.
  
  I tried using the SessionID to create a unique name for each AuthCookie for each browser session. I can get the SessionID in Login.aspx by using Page.Session.SessionID.
  How can I access the SessionID in Application_AuthenticateRequest (Global.asax)?
  Is there a better way to uniquely identify the AuthCookies of each session.
  

• Hi Terence,
  
  There isn't any easy way I can think of to vary the auth cookie by user. Instead you'll want to use a single auth cookie name across all users.
  
  Can you not use the admin name/role and use that as the key to look up the other users activity? This way the admin would be logged in as themselves - but can still get access to the other data.
  
  Thanks,
  
  Scott
  

• Hi Linus,
  
  Can you check with your hosting provider to see if they have this setting locked down above in the machine.config or root web.config?
  
  It could be that for security reasons they aren't allowing people to override it.
  
  Thanks,
  
  Scott
  

• The answer to all of your problems is verry easy!
  
  Instead of changing the cookie or the session timeout, force a refresh. The easiest way to do this is ... put the following line in the form_load.
  
  Response.AddHeader("Refresh", Convert.ToString((Session.Timeout * 60) - 20));
  
  The best place to put this code is in the Master Page Form Load.