Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

idle timeout, and resuming where you left off

 
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Sheriff
Posts: 67637
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 2596
Android Firefox Browser Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Sheriff
Posts: 67637
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
You guys haven't done this much, have ya? I suggest you study this tiny ad:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth
https://coderanch.com/t/751654/free-earth-friendly-heat-kickstarter
reply
    Bookmark Topic Watch Topic
  • New Topic