• Post Reply Bookmark Topic Watch Topic
  • New Topic

idle timeout, and resuming where you left off

 
Tony Smith
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My apologies if this is the wrong forum.

So I have a servlet. In the session, the user has a Login class. I set up a filter so that after so much time, the login is invalidated, and they are redirected to a page that makes them log in.

Once they log in I would like them to resume at the same place they would have landed had the timeout filter not caught them.

Will someone shed some light on how to capture the state before the login, and restore it after the login?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
108
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You need to figure out a persistance mechanism for the state and store it before the timeout occurs.

You could record the state at each step of the way, so that the state can be re-instated upon login. Or you could use a session listener to persist session-recorded state prior to the time-out.

Possible persistance mechanisms: database, flat files, app context (iffy), cookies, and so on...
[ March 02, 2006: Message edited by: Bear Bibeault ]
 
Tony Smith
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your prompt reply.

We've separated the session timeout (which we applications cogs don't control) from the logout timeout, which is configurable on a per-client basis. That is, client X may want the default idle timeout, but client Y may require something much longer.

I'm talking about the login timeout. Our data in the session can keep sitting right where it is since we aren't offing the session.

However, here's the flow as I see it...

1) user is loggged on and was busy but has now sat idle for too long
2) User clicks a button
3) Filter in web.xml notices the timeout
4) User is forwarded to a login page
5) User enters login info and submits the form
6) Filter in web.xml notices but can tell that a login is in progress and allows the request to continue, which invokes a login servlet
7) *something* must now resurrect the request and response instances ignored in steps 3&4 above, and then *somehow* forward the user to the appropriate page. Ideally, I suppose, we'd invoke the filter again and let it do what comes natural.
 
Manish Hatwalne
Ranch Hand
Posts: 2596
Android Firefox Browser Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let the filter set a request attribute/parameter called "prev_page" or similar and pass it on the login page/servlet, the login page after authentication checks for presence of this "prev_page" attribute/parameter and forwards it to that page/action or whatever. The action/filter that determines that session has timed out is the code that can detect from where the request came, and hence can set "prev_page" attribute for further processing.

- Manish
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
108
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I suppose your filter could store the URL that was the target of the submission along with the request params. After login, this information could be used to trigger a POST or GET to the same URL using the same request params which, in theory would be indistinguishable from the intercepted request.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!