Our application has a 30 min auto-expiring session - the session is renewed on server communication.

What is the best way to communicate an expiring session to the user?
My initial thought is a to display a modal warning shortly before expiration with "your session is about to expire [continue]" (better wording?) which allows the user to continue (communicating in the background to renew the session).

Is it ever appropriate to display a session timer to the user?

Is it ever appropriate to expire a session without the user having an opportunity to extend it?

Do users need to be aware of when the session will expire as long as they will have the option to extend it?

I'm not sure about the best course of action but do take care to prevent data loss (when forms that can't be submitted because of session expiration and then are lost without warning.)
–
IncaMay 17 '11 at 13:06

4

Toggle the CD/DVD drive open and closed with flashing lights and a klaxon alarm. "Danger Will Robinson, Danger!"
–
Virtuosi MediaMay 17 '11 at 23:05

Sorry, I couldn't resist and I didn't have anything to add to Jan and Susan's excellent points. Please don't do this. ;)
–
Virtuosi MediaMay 17 '11 at 23:05

6 Answers
6

I believe that a session time out falls under the category of "timed responses". To meet accessibility then, the user should be given the chance to extend, or at the least, be notified it's occurring.

Notifying the user about the length of the session is not a requirement, though it should be determined on a "per application basis". For instance, if it's an application where the user is creating/modifying intricate data, or anything else complex/time consuming - offering them the chance to extend while they're rummaging through their notes could be an important "feature".

Thanks Susan, I had not thought about the accessibility angle - I'll have to research that further.
–
Luke ChardeMay 17 '11 at 18:06

If a session does expire a user friendly web application could automatically save any unsaved data (in a form that wasn't posted yet for example) and restore it once the user restores their session. This can even be done on the client side with HTML 5 local storage: html5rocks.com/en/features/storage
–
RyanJan 2 '14 at 15:33

You can always come up with a scenario in which that warning would go by unnoticed - think lunch break, or an urgent meeting. So I would at first try to make the existence of those sessions as transparent to my user as possible:

reset the session timer as often as possible (e.g. whenever activity is detected) to minimize the occurrence of timeouts

if the session has expired and everything the user did can be restored directly in-place, silently open a new session and re-insert that data - make it look like the session never expired in the first place

if the session has expired and some data cannot be restored in-place, try to make it available by some other means (e.g. a text block or file to copy-paste the data from)

if the session has expired and some data is lost, apologize profusely.

The option of maintaining data has to be application specific. On a banking or ecommerce site, after a session time out, probably should not redisplay financial details or account numbers.
–
Ray MitchellMay 17 '11 at 16:18

@Ray, good point! I primarily had those applications in mind where sessions are more of a server-induced necessity than a security feature.
–
JanMay 17 '11 at 16:23

The first thing to understand is that users don't care about sessions, the session is something you as a developer are forcing onto the user to meet your security/application needs. In an ideal world the session would never expire, like Facebook, Hotmail etc.

That said in some situations such as bank sites we still need to expire sessions as we don't want to leave the door open for anyone to steal our money when we go to the loo or something.

Ok, so when we have to expire a session should we warn the user and give them the option to extend?

Well, Expiring a session is used to log the user out when they are not using the site/application to secure the data. Logically, if the user is still using the site then their session should not expire. Therefore warning the user of impending session expiry becomes irrelevant i.e. if the user is using the site they should never see it AND if the user is not using the site they will never see it.

If you have to have sessions which expire, focus your efforts on recording user activity better so that sessions do not expire for active users.

EDIT: E.g. For our web app I have developed a JavaScript engine which captures client side user interaction's such as, key down, mouse move, mouse clicks, scrolling etc. When a user event is fired an ajax request is sent to keep the session alive.

To avoid numerous ajax calls to the server every time a user moves their mouse you can set the JavaScript to only send an ajax request once every 5 minutes or so. i.e. If last user interaction time > greater than 5mins Then send ajax request to keep session alive.

Thanks for the insight, Archie. So, what would be good opportunities to record user activity (in addition to normal page request / form submission)? ... on input focus? We have a large number of simultaneous users - so every XHR for the sole purpose of session extension is expensive. Maybe I'm veering away from UX with this angle.
–
Luke ChardeMay 18 '11 at 11:50

Good point, I have edited the answer in response to your comment.
–
ArchieVersaceMay 18 '11 at 13:51

@LukeCharde: I guess you can do better by sending the request a few seconds before the session would expire. Just set a timer for this and let each set a boolean (so that you can see if you want to do the request). Or maybe even better: Record the last event time t and extend the session to t + session_timeout.
–
maaartinusMay 18 '14 at 3:07

Depending on your implementation. One "auto-expiration" situation you still might have to handle is the case where their browser decides to eventually delete their cookies, including any authentication tokens. This can be especially annoying for applications like Facebook, because it its a year later, that person may have no idea what their password and username was.
–
Chris DutrowJul 23 '14 at 22:19

I would also strongly recommend against alert() - style message boxes to warn the user about their expired session (some websites do this). You can't rescind it, so if the user had left for lunch, they'll come back to the message box, click "OK" to save their session, and then see themselves logged out anyway. The messages boxes also don't scale across multiple tabs very nicely either.

+1 Great point. Hadn't considered the need for rescindability... so at expiration, change it to a "You have been logged out" msg, right?
–
Luke ChardeMay 18 '11 at 12:07

1

Typically the page is just refreshed back to the login page. If there was text that you were entering, it's usually not — you hit submit, you're brought to the login page, and then it's submitted.
–
Phil CohenMay 18 '11 at 17:07

Phillip, wouldn't the alert—once the session has expired—automatically refresh to the login screen? This way, if the user left for lunch, they wouldn't come back to the message box but rather the login screen.
–
Joel GarfieldJun 5 '12 at 18:59

1

@JoelGarfield: I think in most browsers, alert() blocks the tab from all further activity until dismissed. (In some browsers this blocks all other tabs too!) If you use a non-alert() approach (i.e., making a dialog in jQuery) this won't happen. Sorry for the late response.
–
Phil CohenMar 12 '13 at 3:40

Instead of jquery/ajax calls to keep the session alive, you may consider using javascript setInterval timer to refresh a small 1x1 spacer image when session is about to expire conditionally or always w/o any performance hit.

It depends on the app, of course, but so many of these sites that use this feature (banking, etc) are really designed as "go in, do your thing, then leave". As such, these alerts and messages are really only reminding me that I maybe still have that tab open. I left the page already, no need to tell me session is expiring. Worse case? I log back in.

Now, the one (big) exception would be any sort of large data input where a user could potentially enter a lot of data, never submit, then lose their session. However, in those scenarios, Ideally there'd be some sort of auto-save functionality going on (ala Google Docs).