Your Ajax call checks for an error status and redirects. I used to handle this with a filter that checks for XHR and send back something more appropriate.
Dave On Thursday, January 27, 2011, CRANFORD, CHRIS <chris.cranf...@setech.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
