Controlling Browser Sessions

A question came up in the forums recently that I thought should be added to the documentation since it is probably a fairly common question.

Is there any way to log off a session due to inactivity so that if a user walks away from a public computer without logging off, protected resources will be unavailable without re-entering password?

The answer is as follows:

Yes on the <forms element in Web.config is timeout="20160"

This property is in minutes and the default value is equivalent to about 2 weeks. This property controls expiration of the forms auth cookie, if the specified number of minutes passes with no browser requests from the user the cookie is expired and the user will have to login again.

Keep in mind that if you do set a low value like 5 for 5 minutes, then you should probably also uncheck the Allow Persistent Authencitcation Cookie setting in Site Settings. It would be a bad user experience if the user checks "Remember Me" on the login page and then his is logged out after a short time of activity. Note that this Remember Me checkbox only determines if the cookie can survive closing the web browser, the cookie is still subject to the timeout regardless of whether the web browser is closed. But if the browser is closed and re-opened before the amount of time then the user will still be authenticated.

Also keep in mind another bad user experience if you set a low number like 5 minutes. Suppose the user is editing a large article and then gets sidetracked into a conversation without saving and 5 minutes goes by, then he tries to save the content but it fails because he is no longer signed in and the edits are lost which can be very very frustrating for a user.

We have a session keep alive that is used on edit pages to prevent the user session from timing out while editing but this is based on the IIS session timeout (which defaults to 20 minutes) not on the auth cookie timeout. So the sessions keep alive makes a background request from an iframe in edit pages but the frequency is based on the session timeout so if session timeout is 20 minutes it makes a background request at 19 minutes to create activity to keep the session alive. However 19 minutes is too long to wait if the auth cookie will expire sooner than the IIS session. To account for this I just now added a new config setting that will be available in the next release:

<add key="SessionKeepAliveFrequencyOverrideMinutes" value="-1" />

if you put a value greater than minus 1 it will use that number of minutes for the session keep alive frequency. ie if you put 1 then it will make a background request from the edit page every 1 minutes so that would be frequent enough to keep the auth cookie alive if the user has the editor open and gets side tracked. But then again if you choose to do that it means that if the user opens an edit page and walks away from the computer you are back at the same security problem because the edit page would keep the auth cookie fresh.

So, as usual, there are tradeoffs between security and user experience. If you are worried that the user would leave the machine unattended with the editor open then you would not want the session keep alive to make requests frequent enough to keep the auth cookie alive, but, it can lead to user frustration if the user had unsaved edits and his auth cookie expired.