In our application upon a successful authentication, the HttpSession
property setMaxInactiveInterval is set to whatever our application's
idle time out is so that if this value is reached, the session is
destroyed and upon the next request to the server, the user will be
redirected to a login page.
This concept worked just fine until I wanted to introduce dynamic
content via AJAX. Now I need to be able to control when the session
truly expires by user interaction versus dynamic interaction by an AJAX
enabled web page.
I am considering using an interceptor concept where I group by actions
into two groups; ones considered AJAX calls and those which are not
meant to return JSON data. When the user selects a non-AJAX action; an
interceptor runs and performs the following checks:
1. Is HttpSession valid?
No -> LOGIN
Yes -> Step #2
2. Does HttpSession contain value holding time of last User request?
No -> Create one, store it in session, proceed
Yes -> Compare current time to this value.
If difference > timeout -> LOGIN
If difference < timeout -> Step #3
3. Update HttpSession value of last request to current time and
Proceed to handle request
This way, I validate whether the HttpSession has truly expired due to
lack of USER input versus automated INPUT from an AJAX call.
For an AJAX based call; this interceptor would not fire. While the idle
time on the HttpSession would be reset; the time of last request isn't
updated; thus allowing user interaction to continue to track idle
timeout.
What have others done in your applications so that you can handle proper
timeout of a sessions despite the fact your application may be getting
AJAX requests refreshing the idle time on the session object?
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
