General help

 
 
Picture of Mark Johnson
Usability: Session Timeout warning
Group Developers

I've had a few reports from users whereby they're editing a page (such as an assignment grading page) over the course of a lesson, and by the time they click save their session has timed out, so their data is lost.

I've implemented a rudimentary solution to this, whereby I set up a javascript timeout for the length of the session minus 5 minutes to display an alert warning the user to save their work.  Something like this would be a nice easy usability win for 2.3 and great for building user confidence in the system. 

I'm happy to share my solution for this, it's implemented as part of the theme at the moment but could be easily transplanted to the core.

 
Average of ratings:Useful (1)
Picture of Olli Savolainen
Re: Usability: Session Timeout warning
Group Developers

Sweet! smile

What I have gotten accustomed to considering the most seamless way to make a web app reliable in such a situation, from a user point of view, is to carry out the action the user wanted to do, after they have logged in again, without losing the data. The user would not have to think about it or get scared of a warning, but they could trust the system to be reliable without the user's help.

I guess something like the following could work for the implementation.

When a user submits something but their session has timed out,

  1. Store the user's submission contentin a temporary location on the server, and associate that content with an ID for that temporarily stored content
  2. Show the user a login form (that has the ID of the temporarily stored content as a hidden input field parameter) with a message such as "You have been logged out due to a timeout of your session (you spent too long without making an action in Moodle). Please login to save the information you entered.").
  3. When the user logs in again (with the temporarily stored content ID) read the submission from the temporary storage, and perform the action the user was originally trying to carry out.
  4. To keep things clean: If the user does not log in again on that login form with the temporarily stored content ID, delete the temporarily stored content after, say, 24 hours of storage.

Does this make sense to you?

I am not sure if the temporarily stored content ID could be replaced with a cookie kept with the user even when they are logged out.

I wonder how long session timeouts do apps like Google Docs have, though, and if something could be learned from them.

This is something I thought about roughly while originally creating this wiki page, but I seem to not have expressed it too broadly back then.

 
Average of ratings:Useful (1)
Picture of sam marshall
Re: Usability: Session Timeout warning
Group DevelopersGroup Particularly helpful MoodlersGroup Testers

That would be awesome but it might be difficult to implement and I don't think it can work in all cases, primarily with different auth plugins.

For example, we use a custom plugin with SSO, so Moodle doesn't control the login screen; if you submit a form after Moodle's timeout has expired, but when the SSO timeout hasn't, then you'll automatically be granted access again (logged into moodle behind the scenes) with no login interface: you'll just get directly to the helpful 'incomprehensible error about your form data not being valid for no particular reason' page smile

Or, worse, if you submit a form after the SSO timeout has expired too, then you'll be redirected ignominiously to the standard SSO login page (and there's not much moodle can do about this, at least in our particular system - it happens before the php layer) which won't know about moodle stuff, we can't change it, and it will lose your form data whatever happens.

A different, easier possibility is to automate the timer approach described. In other words, rather than popup a dialog (ugh!), just make the JS request something - anything - from the server before the session runs out. Then it won't run out, problem solved.

Yes this means if a user leaves their browser open then they can hold a session open on the server forever but I think if you combine it with reducing the actual session length (say from 2 hours to 30 minutes) it would most likely end up reducing the amount of sessions open at any one time (would have to experiment, obviously). We should be able to afford users making a low-impact php request every 29 minutes while they lurk on a page, or even several if they lurk in lots of tabs.

--sam

 
Average of ratings:Useful (1)
Picture of Olli Savolainen
Re: Usability: Session Timeout warning
Group Developers

Ugh about having SSO happen before the PHP layer. So you mean that every HTTP request goes through the SSO layer and it can intercept anything going Moodle's way?

Meddling with session expiry seems risky. I would like to have a security expert review the idea before implementing something like that.

But yeah, it still seems the only reliable option for systems having such SSO would be your session refreshing server request, or also including the form data in that server request,  essentially making up a sort of low-frequency autosave. (This would probably have to be disabled for binary data/file upload fields, though, to keep the request size small.) In the latter case though, we still do not know if the user actually submitted the form at the time it is saved, so actually submitting that data after logging in again would need to be confirmed by the user, which seems like quite a bit of UX overhead.

Also submitting it might not make sense anymore at that time (if the forum thread they were posting to got deleted, for example).

Hm, we probably can't change the session length for current Moodle installations, right?

Stats about how much Moodle's own user database and login system is used would be great so that it could be determined if it would still be worth it to implement the ideal setup just for those cases.

 
Average of ratings: -
Picture of Mary Rydesky
Re: Usability: Session Timeout warning
 

If I follow your comment in the next to final paragraph, you are questioning changing the session length.  I am running 1.9 and just changed the session timeout.  Seems we get a request about once a year to alter ths and now my folks want it to be 20 mintes!  So yes you can.  Go to Administration > Server >Session Handling > Time out.  You have numerous preset options.  Want something different?  It can be coded!

 

Now my question is about a path to a message (if there is one) that alerts the user that the sesion is about to expire and to do something (save?) and reactivate the session.  Anyone have an idea?

 
Average of ratings: -
Picture of Mark Johnson
Re: Usability: Session Timeout warning
Group Developers

Hi Mary,

I added the message by putting a js_init_call for this function in my theme's footer. $CFG->sessiontimeout is passed as the timeout argument.  It's hacky, but it's a start:

init_timeout_warning: function(Y, timeout) {
    timeout = timeout*1000;
    if (timeout > 300000) {
        delay = timeout-300000;
        setTimeout(function() {
            msg = 'Your session will timeout in 5 minutes.  After this you will be logged out and you will ';
            msg += 'no longer be able to save.  If you have made changes to this page, please save your changes ';
            msg += 'now, and the timeout counter will be reset.';
            alert(msg);
        }, delay);
    }
}
 
Average of ratings: -
Tim at Lone Pine Koala Sanctuary
Re: Usability: Session Timeout warning
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

I can't see any reason to have a 20 minute session timeout. Well, if you have a sadistic admin who likes to make users cry then possibly wink Why is such a short time-out being proposed?

 
Average of ratings: -
Picture of Mary Rydesky
Re: Usability: Session Timeout warning
 

Oh, Tim, you gotta know--I fully understand!  But when a 'client' (read what ever the decision makers are called in your organization) thinks that is a wonderful thing to have 20 minute time outs, I have the responsibility of asking what my Moodle colleagues would recommend and then reporting to the client as best practices. In some cases, the clients' desiress vary from my personal choices or from my store of Lessons Learned and this is one such debate!

 
Average of ratings: -
Picture of Olli Savolainen
Re: Usability: Session Timeout warning
Group Developers

Thanks Mary. I was being unclear, sorry.

I actually meant that exactly because individual Moodle installations can change the session length, it seems unfeasible or at least very risky to change that session length that has already been customized in many current Moodle installations, to any given number of minutes that would come fixed in a new Moodle version.

sam's proposition, above, seems to require that we would do that, and I am trying to figure out the repercussions of trying.

 
Average of ratings: -
Picture of Mark Johnson
Re: Usability: Session Timeout warning
Group Developers

I like the idea about doing a small XHR, I suppose it would just need to request any file that includes config.php?  It does raise some security concerns, but no more so than people walking away from their computer without locking the screen.

 
Average of ratings: -
Picture of Mark Johnson
Re: Usability: Session Timeout warning
Group Developers

Something ocurred to me last night that would make this even better.  Instead of just blindly doing an XHR when the session is about to expire, you could set up event listeners on the document for keypress and mousemove 5-10 minutes before the session expires, and only send the XHR if they're actually active.  This means the session won't be prolonged if they've wandered off from their computer entirely (good for security) but will if they're actively using the page (good for UX).

 
Average of ratings: -
Picture of sam marshall
Re: Usability: Session Timeout warning
Group DevelopersGroup Particularly helpful MoodlersGroup Testers

You have a point, but in my experience the main reason people want this feature is lunchtime (or other meal), so it's mainly the 'unsecure' behaviour they want... smile

I actually don't think session timeouts are much of a security feature against that type of threat. Say the timeout is 20 minutes - say somebody wants to do something malicious with your account - you're using it in a computer lab, then you go to the toilet - even a 20 minute session expiry is plenty of time for somebody to go over to your computer and do whatever they like.

On the other hand, if you actually lock your screen when you leave the computer in an area other people can access, then it isn't a problem even if the session timeout is (current default) 2 hours, or automatically prolonged into infinity, so it would be good to let them do that (midway through editing a form, lock your computer and go to lunch).

--sam

 
Average of ratings: -
Picture of Mark Johnson
Re: Usability: Session Timeout warning
Group Developers

Is it possible then, to simply have the session not expire until the browser is closed? If PHP lets you do that it would be far simpler to have that as an option rather than faffing around with Javascript.

 
Average of ratings: -
Tim at Lone Pine Koala Sanctuary
Re: Usability: Session Timeout warning
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

There has to be some expiry, because Moodle does not know if the user just closes their browser.

If you could ensure that all users finished thier session by clicking the Log out link, then there would be no problem. Session could last until the user clicks Log out, but users don't behave like that. They just close their browser, and Moodle does not know that.

Therefore, you have to have some time-out, to clean up the old stale sessions, but it can be quite long. The only down-side is that the longer the time-out, the more 'current' sessions need to be kept on disc, but disc is quite cheap.

 
Average of ratings:Useful (2)
Picture of Mark Johnson
Re: Usability: Session Timeout warning
Group Developers

Ah yes, I was thinking of the session as the cookie rather than the data stored on the server.

So all in all Sam's suggestion of the small XHR just before the session expires seems like the best solution.  Allows the server to clean up session data after the user's actually closed their browser, but doesn't log them out when they're lurking on page. 

Unless someone beats me to it I'll knock up some code next week.  If this was going to go into core where would be the best place for it to live (both the javascript method and the js_init_call)?

 
Average of ratings: -
Picture of Ashley Holman
Re: Usability: Session Timeout warning
Group Developers

Hi,

I've developed a session timeout alert which occurs via a javascript modal dialogue.  I've put the code here in case anyone is interested: http://tracker.moodle.org/browse/MDL-34498

 

It also automatically extends your session if you are making edits in TinyMCE, so as long as you don't go idle for longer than $CFG->sessiontimeout, you can edit forever.

 

5 mins before session expiry it will warn you, and give you an option to extend.

 

Cheers

Ash

 
Average of ratings: -