What is the best way to protect user inputs (not yet submitted) from session timeout?

Question

I develop and maintain small intranet web apps(JSP and Resin).

Some users takes so much time to complete the forms that, when they submit, they lose all their input data because of session timeout.

Currently I prolonged session timeout to 30 minutes and display count-down clock till session timeout on top of the page, but, I think their must be better ways to protect user inputs.

What is the best practices?

---

Addendum Our users make several kind of reports with the web-app, and the whole contents of each report are stored in a JavaBean stored in the session.

As suggested by some, Ajax or iframe should do the quick fix.

I now know that it is better not to abuse session with heavy objects, but I'm not sure how best to refactor current mess. Some people suggested to make the web-app stateless. Any suggestion for refactoring is welcome.

Answer 1

I've only recently needed to look at solutions to this problem.

The direction that looked most promising was using AJAX to periodically check if data was entered, and send it to the server. If the browsers running in your company support AJAX, this is one possibility.

Another possible solution could be to split the forms up, so that each section is small enough to be filled out and submitted within the session timeout.

Answer 2

You could store the data in a cookie every once in a while, use Gears as a temporary storage (if the data is complex or requires more than 4K storage) or send the temporary data to the server every n second using AJAX.

Answer 3

This may or may not be the case with your framework, but I think that if your page just uses AJAX to call the server every five minutes (or whatever), then that will keep your user's session alive. You don't even have to do a partial save of your form this way.

Answer 4

Make your applications stateless on the server side. You can include any state you need to maintain in hidden input fields. If security is a concern then you can encrypt the data before putting it in the field.

An example is putting something like this in your form:

<input type="hidden" name="user" value="bob" />
<input type="hidden" name="currentRecordId" value="2345" />
<input type="hidden" name="otherStuff" value="whocares" />

The main advantage of this is that your web app can do everything it needs to with just that page. It doesn't need any session variables because everything it needs is in the page it just received. Now it doesn't matter how long they take because there is no session to expire.

A secondary advantage is that it reduces the load on your server because it isn't polling your users periodically.

Answer 5

If you are creating an application for a limited number of users (e.g., a company intranet) and you don't want people to have to keep logging in all day or have them lose their input information when sitting for extended periods of time, you can keep sessions open indefinitely only for people that have their browser open to your website without setting the session timeout to not expire. As soon as they close the website then the session will expire as normal.

What you need to do is add a hidden iframe somewhere on the page. Have the iframe point to a simple html document served by your app server that has a meta tag in it to refresh every 29 minutes (for a session that expires in 30 minutes). This way, as long as the person has your web page open, their session won't expire. However, when they navigate away from your site it will expire as normal. You get unlimited session lengths without the downside of sessions that grow out of control.

I successfully deployed this solution in an enterprise environment at a previous place of employment. The web app replaced an old green screen application and it was unacceptable for them to go to lunch and have the application expire on them, for example.

Let me know if you need more of an example.

Answer 6

I'd recommend looking into a stateless alternative (something that does not rely on session attributes) to what you're doing.

We may be able to help more if we know what exactly it is you're relying on sessions for.

Answer 7

Umm..

What about displaying a prompt to the user about the session about to be expired -- save data (say 5 min before), so that they can save the data. This way they know what they have to save and in case the session really needed to be expired, it will be done afterward if they don't respond.

This is an alternative in case when you want to avoid a continuous ping to server using AJAX.

Answer 8

Don't use the session object. This is a cause of all sorts of usability problems - as you are discovering.

It's my golden rule of web application development: don't use the session.

Having said that, use it sparingly for things that just can't be done otherwise.