Jaa

Understanding Session Lifetime

  • Artikkeli

Back in May of last year, I discussed changes we made in Internet Explorer 8 to make the browser’s session handling behavior more predictable. Specifically, we introduced a “New Session” item on the File menu—this menu item explicitly creates a new browser session which doesn’t share session information with the existing session. From the command line, you can open a new session using the -nomerge command line option.

We also changed other codepaths to ensure that no matter what other method you use to open a new IE window or tab, e.g.:

    1. File > New Window
    2. Hit CTRL+K
    3. Hit CTRL+T
    4. Call window.open() from JavaScript
    5. Click on a link in your mail program
    6. Click a QuickLaunch shortcut
    7. Double-click on the “blue e” on your desktop

...the new window would run in the same browsing session as an existing window[1].

As I outlined in that post last year, pre-IE8 prior behavior was somewhat confusing to users who didn’t realize that they’d get a different number of active sessions depending on how they launched Internet Explorer. Beyond improving consistency, the new behavior also improves performance, and thanks to LCIE and crash recovery features, it doesn’t negatively impact reliability.

One downside to this change (or any change that’s visible to the user) is that there is a period of adjustment because some scenarios work slightly differently. When things change, the misunderstandings that users hold in their mental model of how the browser actually works are often spotlighted.

For this particular change, the most common complaint I’ve heard is “Something changed—IE8 won’t let me log out of a website anymore!?!”

When I ask for details, the scenario is always something like:

  1. Open three browser windows by clicking on the desktop icon a few times.
  2. Open a new IE browser window from the desktop.
  3. Navigate that new browser window to GMail or another mail website.
  4. Use the web mail window.
  5. Close the web mail window using the red “X” in the title bar.
  6. The user expects to be logged out.
  7. Open a new browser window or tab.
  8. Navigate that new window to the web mail site.
  9. Observe that you remain logged into the web mail site.

Now, users will try this exact set of steps on IE7 and at step #9 they will see that they are not logged in. In contrast, when they perform this set of steps in IE8, they will see that they are logged into the web mail site automatically.

What happened?

In IE7, Step #1 creates [Session1, Session2, Session3]. Step #2 creates [Session4].

In IE8, Step #1 creates [Session1], with three windows sharing just one session. Step #2 creates a fourth window in [Session1].

So, when you get to Step #5 in IE7, the window is closed and [Session4] is destroyed, so the user is logged out. In IE8, Step #5 merely destroys one window in [Session1], leaving three more windows and [Session1] still alive. Thereafter, when the user opens a new window in Step #7, that new window is opened/merged into the existing [Session1].

What very few people realize is that both IE7 and IE8 work in the same way if a small change is made in the steps:

  1. Open three browser windows by clicking on the desktop icon once and clicking File > New Window twice.
  2. Open a new IE browser window by clicking File > New Window.
  3. ...
  4. ...
  5. ...
  6. ...
  7. Open a new browser window or tab using File > New Window or File > New Tab.
  8. ...
  9. ...

In this set of steps, both IE7 and IE8 create only one browser session, and closing any one window will not log the user out.

Securely Logging Out

We’ve just learned that a browser session ends when you close the last browser window within a given browser session. So is that what you need to do in order to fully log out of a website?

There’s usually a better alternative: Click the site’s Logout button. When you do that, the site will typically expire your session on the server side, and send a command to delete your session cookie on the client side. You may still wish to close your browser windows (so someone can’t simply click “Back” to see the last pages you saw) but after you click Logout, the site should force you to log in again to make any changes or retrieve any new information.

Session Information (Not just cookies!)

A common follow-up question is: “What information is a part of a session?”

  1. Session cookies
  2. sessionStorage
  3. HTTP Authentication (e.g. Digest or Basic HTTP credentials)
  4. HTTPS Client Certificates (e.g. sites that use certificates or SmartCards)

A site can clear its own session cookies by simply sending down new cookies of the same name (and path/domain) with an expiration time in the past. To clear its own sessionStorage, the proprietary clear method can be called. To clear HTTP Authentication and HTTPS client certificates, IE6 SP1 and later support the ClearAuthenticationCache command:

 document.execCommand("ClearAuthenticationCache", false);

 

It’s worth mentioning that the ClearAuthenticationCache command clears ALL session cookies, Authentication, and Client Certificates for ALL sites running in the current session, so it’s definitely a command to execute judiciously lest you drive your site’s visitors crazy. Currently, no other major browser that supports the ClearAuthenticationCache command, although Chrome and Firefox have both acknowledged the problem and are discussing possible solutions.

Until next time,

Eric

[1] New windows will not be merged into an existing session if they are “incompatible”—e.g. we won’t merge sessions across UAC Integrity levels, and we won’t merge sessions unless options like InPrivate Browsing (-private) or No Addons Mode (-extoff) match the existing session.

Comments

  • Anonymous
    April 04, 2010
    Thanks for the pointer to http://code.google.com/p/chromium/issues/detail?id=5497.  I'll try to get that implemented soon.

  • Anonymous
    April 08, 2010
    Hi Eric, I was recently having trouble loging in to my online banking account. The usual symptom... could not login with IE8 (login page did nothing on submit) but I could with another browser. At first I thought it was my overly long UA string, but reducing its length did not work. I then fired up Fiddler to have a look at IE8's' requests and responses. Nothing obvious. I then selected the Session Items in Fiddler and cleared them. Behold.... I could then login to my bank account. What is going on there? Is fiddler using ClearAuthenticationCache? If so surely secure bank login sites is the ideal case where we should use it. Regards.

  • Anonymous
    April 08, 2010
    @Rob: No, Fiddler doesn't call ClearAuthenticationCache (or any other URLMon APIs either). If you use the "Clear Cache" button in Fiddler, it clears WinINET/IE's Temporary Internet Files cache, but it doesn't sound like that's what you did. Even if Fiddler had called ClearAuthenticationCache, there's no explanation as to why that would fix the problem you describe. "Doesn't submit" problems are typically related to JScript running on the client.

  • Anonymous
    April 09, 2010
    The comment has been removed

  • Anonymous
    April 09, 2010
    FWIW: The use of the comma operator there is a bit odd-- a semicolon would be more typical.

  • Anonymous
    June 07, 2010
    blogs.msdn.com/.../session-management-within-internet-explorer-8-0.aspx discusses a registry key available to disable Frame Merging. There's a performance impact to using this, of course, since you'll end up with more frame processes.

  • Anonymous
    July 16, 2010
    The comment has been removed

  • Anonymous
    January 28, 2011
    Hi, EricLaw,   I tested a https site which uses smart card, but I find when I  open a new windows, it still need to select the cert and input the pin code. So why? Won't they merge the ssl session?  Regards.

  • Anonymous
    January 28, 2011
    @EricTan: I might be mistaken, but I don't believe SChannel's client auth handles can be shared cross-process.

  • Anonymous
    January 28, 2011
    Hi  EricLaw:    I notice that you said session Information contained https client certificates, a new window will share session in IE8. You mean the certificates used in SSL?  If a new window or tab share the certificate, doesn't it mean that they share the ssl chamnel in order to use the same certificate? Regards

  • Anonymous
    January 28, 2011
    @EricTan: Yes, IE8 is supposed to put new tabs/windows launched to the same host into the same process when a client certificate is in use in the original process. If you have a repro site showing that's not happening, can you please email me a URL?

  • Anonymous
    January 29, 2011
    Hi, EricLaw. I used fiddler to watch the process id of different tabs with same domain, such as vip.icbc.com.cn/.../index.jsp. I found that the process id was different. But the request of the some tab had the same process id.  By the way, I used smart card to log to corporbank.icbc.com.cn, it 's odd that I had to select the certificate and input the pin most of the times when I opened a new window, but still have chance to log in without the process of selection and input. Can you exlain me it.   I'm sorry I am new here, so I don't know how to get you email from this site.   Regards.

  • Anonymous
    March 03, 2011
    @Eric: I should have clarified-- the "leashing" behavior that keeps HTTPS sessions in the same process only occurs when one HTTPS page opens another HTTPS page using window.open(). If you navigate two independent tabs to the same HTTPS site, they aren't guaranteed to be kept in the same process.

  • Anonymous
    February 02, 2012
    Hi @Eric, Thanks for the very usefull entry. Just a question. Is there any way to perform a ClearAuthenticationCache just for the current domain? is window.sessionStorage.clear() the way?

  • Anonymous
    February 02, 2012
    @Dani: No, there's no way to perform this function for just one site or domain. (It's a reasonable idea that we've considered, but not something that we've gotten many requests for). Clearing sessionStorage will not touch cookies, HTTPS client certs, HTTP Auth creds, or the TIF per-session cache.

  • Anonymous
    October 21, 2014
    Hi @EricLaw, Thanks a lot for this useful post. I still have a question, because when I read that clerAuthenticationCache also clears HTTPS client certs, I understand that once I logout from a site, if I want to login again using HTTPS client certs, in case of a smartcard, I should have to introduce again the PIN code. Am I wrong? I created a simple PoC in order to test this, I introduce the smartcard and I login, afterwards I logout and without retrieving the smartcard I login again. No PIN code requested for the second time. I do this with IExplorer v11. Am I doing something wrong? Or did the implementation of this command change? Thanks, D.

  • Anonymous
    October 21, 2014
    @Darizotas: I would expect that you'd be prompted to select which client certificate to send again, and probably would be required to enter a PIN again, although the latter operation might not have ever been required. It's also possible that this worked at one time and later broke in one of the many process-refactorings that have occurred over the years. If you have a repro, you should probably file a bug on Connect.microsoft.com so the IE team can have a look. (You may wish to confirm that session cookies are being cleared, a sign that the call to the API was correct).

  • Anonymous
    October 22, 2014
    Thanks for your answer @Eric. I can confirm you that the session cookie and HTTP credentials are cleared :-)  But not the client cert. So I guess that I will have to clear the SSL state.