27

In web.config, I set timeout in the sessionState to 20 minutes. According to MSDN, this timeout specifies the number of minutes a session can be idle before it is abandoned. In IIS 7, DefaultWebSite->Session State->Cookie Settings->Time Out automatically is populated with timeout value set in web.config, which in my case is 20 minutes. Also, Application Pools->DefaultAppPool->Advanced Settings->idleTimeout, I set it to 10 minutes.

Then I made two tests: First test: I logged in my web app at 3:45pm, idling for 10 minutes. At 3:55pm, I tried to use my app, I got kicked out. I think the idleTimeout comes in play.

Second test: I logged in my web app at 4:00pm, play with the app at 4:05pm, 4:10pm, 4:15pm and 4:20pm. I expected being kicked out at 4:20pm. But I was not. I thought the session state timeout (20min) in IIS 7 is the the maximum amount of time a user session can be active before the Web Agent challenges the user to re-authenticate. Apparently from this test, it is not. Can anyone explain that to me? Also, how could I set the timeout for above case?

0

1 Answer 1

39

Session time-out is a sliding time-out that is reset for a user to the configured value each time they visit the server.

The Application Idle time-out kicks in if there have been no requests to your application for that period of time.

The usual scenarios is therefore:

Time User A User B Session States
12:00 Visits Page1 A: New Session, Time-out: 20 minutes
12:02 Visits Page2 A: Time-out reset: 20 minutes
12:10 Visits Page1 A: Time-out: 12 min; B: New: 20 minutes
12:15 Visits Page2 A: Time-out: 07 min; B: Time-out: 20 min
12:22 A: times out; B: 13 min remaining
12:32 Application Shuts Down (Idle time reached)
12:35 Visits Page3 A: New Session Starts

If User A were to return to the site after 12:22 they would have a completely new session, and any values you've stored in there previously would be lost.

The only way to ensure that a session persists over application restarts is to configure either a SessionState service or SQL Session States, and ensure that you've configured the machine.key so that's it not AutoGenerated each time the server restarts.

If you're using the standard ASP.NET mechanisms for authentication, then ASP.NET will will issue two cookies to each user:

  1. Authentication Token: Controlled by the Authentication time-out setting, allows the user to be auto logged in to your site if the cookie hasn't expired, this can be fixed or sliding, and defaults to 30 minutes, which means their authentication token can cope with a longer "idle" period than their session.
  2. Session Token: Controlled by the Session Time-out setting, allows your application to store and access per-user values during the lifetime of their visit.

Both of those cookies are encrypted using the MachineKey - so if your application recycles and generates a new key neither of those tokens can be decrypted, requiring the user to log in and create a new session.


Responding to comments:

  1. The 20 minute session time-out relates to items you've placed in the users session object (HttpSessionState) using the Session.Add(string, object) method.
  2. That depends. If you've correctly configured the machine.key, authentication tokens will still be valid, and if your sessions are no longer "InProc" these will also persist through application restarts and will still be readable - see notes above.
7
  • but why I didn't need to re-logon during my second test?
    – GLP
    Commented Feb 21, 2012 at 21:52
  • Because each time you visit the server the timer is reset - as per my table. Commented Feb 21, 2012 at 22:05
  • Thanks Zhaph, I still have two questions, (1) what will the 20 mins affect? (2) Is B will have to relogin after the Application Shuts Down?
    – GLP
    Commented Feb 22, 2012 at 14:13
  • BTW, I just checked my web.config, we set the form timeout to 2880 min. So it should not cause any trouble :)
    – GLP
    Commented Feb 22, 2012 at 14:38
  • Thanks for your reply. I just tried to duplicate your test in my environment. Interestingly, at 12:22, A's time was up, but somehow A was not kicked out. I suspect the idle timeout was reset by B. Can you point me out which settings got messed up?
    – GLP
    Commented Feb 22, 2012 at 15:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.