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 -> /login.jsp. 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 properly. > -----Original Message----- > From: Scott [mailto:stanl...@gmail.com] > 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? > > > > From: CRANFORD, CHRIS [mailto:chris.cranf...@setech.com] > 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 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 > > _____ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1204 / Virus Database: 1435/3406 - Release Date: 01/27/11 --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
