session timeout in login page

[Michael Swierczek]

Here's my problem. It's absurdly simple, but I'm missing the obvious answer.

I have a web application that lets Joe User walk up and take surveys without any authentication. It also allows Jane Counselor to log in and view survey data. I want survey sessions and logged-in sessions to timeout after periods of inactivity.

But the "Start survey: please enter your age..." page and the "Login: please enter your username and password..." page to never time out. Currently, if either page sits open for longer than the timeout period, entering the data and clicking submit generates a 408 Session timeout error.

From reading bits of the 2.4 Servlet specification, this Session timeout is expected behavior. Is there some simple solution to this that I have missed? I see three solutions, but I am wary of all of them.

1. I can refresh the first question page and login page at time intervals less than the session timeout. This is the current solution, and it is inadequate. As a minor point, it adds a lot of needless traffic to the web server when kiosks with the software are unused for days. As a major point, if network connectivity is lost for some time period overnight, the periodic refresh leaves the browser open to a '404' error.

2. I'm using Tomcat 5.0.28. God bless open source, I can modify
src\jakarta-tomcat-catalina\catalina\src\share\org\
apache\catalina\authenticator\FormAuthenticator.java
to create a new session on the spot when it gets a username and password but no previous session. But I'm assuming the Servlet specification was written the way it is written for a reason, even if that reason is not easily apparent to me.

3. I can disable global session timeouts for the entire context, and separately (and painfully) write a separate session timeout mechanism that is checked and updated manually by every Action-Mapping class in my web application except for the single two Action-Mappings affecting the first survey question page and the login page. This will work, but it's a hideously ugly workaround.

I'm hoping I've just missed something painfully simple. Any ideas?

[Bear Bibeault]

4. Don't use the session timeout at all.

Employ your own "security timeout" and use a servlet filter to easily track it.

[Bear Bibeault]

See previous discussion at:

https://coderanch.com/t/118721/HTML-JavaScript/Session-time-out-AJAX

[Michael Swierczek]

Thanks for the response! I forgot about the Filter. That's worlds easier and more extensible than modifying every single class that has an Action-Mapping.

However, while discussing the problem with a colleague, I encountered another angle on the problem I need to consider.

If we don't expire sessions, we'll have hundreds or thousands of dead sessions needlessly consuming resources on the server. I'll need to research how Tomcat handles this - presumably the data is serialized and written to disk.

More importantly, this still doesn't handle what happens if a web browser is left open to the login page and the Tomcat application for whatever reason restarts. The session id will still be expired, so the user's first attempt at a login will fail. I'm going to look for another Filter or similar gate in the pipeline of the software that handles this.

[Bear Bibeault]

Originally posted by Michael Swierczek:
[QBIf we don't expire sessions ... [/QB]

In the scenario I described, session do expire to prevent just that. But the session expiry is not relied upon as the timeout mechanism.

I forget what the session timeout is set to on our production systems, but it's long enough that users who just step out to a lunch or a meeting don't encounter it, but those who don't return eventualkly get expired.

[Michael Swierczek]

Some of our workstations at customer sites are in kiosk browser mode open to the start page, and have the potential to be unused for weeks. Timeouts are still an issue.

[Eric Pascarello]

Can I ask how would that page need a session timeout in the first place? Wouldn't that first page be sitting outside of authetication since it does not need it until that click the submit buttons? The session would start of the completion of the first step?

I might be missing a piece of the puzzle here.

Eric

[Bear Bibeault]

You know, I actually missed this in your first post:

entering the data and clicking submit generates a 408 Session timeout error.

Odd. Most containers will simply start a new session.

What are you using?

[Michael Swierczek]

Originally posted by Eric Pascarello:

I might be missing a piece of the puzzle here.

Eric[/QB]

No, I'm fairly certain that I am missing a big piece of the puzzle. I'm using Apache Tomcat 5.0.28, and I have my security container for anything with /admin/ in the URL. The login entry is at blah/admin/login.do.

If the user has just opened the login page and logs in, everything is fine. If the page sits for a few days, and then a user types a username and password and presses 'submit', they get a 408 Session timeout error and must go back to the login page. I want to prevent that from happening.

The session timeout occurs because when they press 'submit', they send the session ID from a timed out session on the server. But obviously, this shouldn't matter - a new session should be created for them.

I'm guessing I'm missing a trivially easy solution.