struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: AJAX & Sessions
Date Fri, 28 Jan 2011 03:05:05 GMT
Depends on the page; but yes many are user initiated.

All the AJAX tutorial examples I have seen always seem to return SUCCESS
in the call; however I have yet to see how I would return an error to my
AJAX call. 

Lets take an example, I have a LoginInterceptor which checks the
HttpSession to see if its invalid or if the HttpSession is missing the
our session user data object.  If either condition is met; the
interceptor returns LOGIN.  This LOGIN maps to a global result ->

In an AJAX situation; lets say that upon clicking a button, a call is
made to the server, it forwards to SUCCESS and the JSP tidbit served
back is placed in a DIV.  How would you handle clearing the screen and
sending the user to the LOGIN page without putting the LOGIN page in
that DIV?

I really want to implement AJAX/JSON stuff properly in this application

> -----Original Message-----
> From: Scott []
> Sent: Thursday, January 27, 2011 8:37 PM
> To: 'Struts Users Mailing List'
> Subject: RE: AJAX & Sessions
> Are these Ajax requests *not* human initiated?  IOW, are they timers?
> Sent: Thursday, January 27, 2011 8:29 PM
> To: Struts Users Mailing List
> Subject: AJAX & Sessions
> 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
> 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;
> 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:
> For additional commands, e-mail:
>   _____
> No virus found in this message.
> Checked by AVG -
> Version: 10.0.1204 / Virus Database: 1435/3406 - Release Date:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message