I'm so glad I follow this mailing list! I wasn't looking for this answer, but This is quite helpful! Thank you, Chris!
Beez -----Original Message----- From: Chris Pratt [mailto:thechrispr...@gmail.com] Sent: Friday, January 28, 2011 12:08 AM To: Struts Users Mailing List Subject: Re: AJAX & Sessions Here's a couple of the ways I handle it: <action name="edit-ingredient" class="ingredientEditAction"> <result name="success">ingredients</result> <result name="login-required" type="httpheader">401</result> <result name="failure" type="httpheader">500</result> </action> <action name="converter" class="converterAction"> <result type="json"> <param name="root">factors</param> </result> <result name="login-required" type="json"> <param name="errorCode">401</param> </result> <result name="failure" type="json"> <param name="errorCode">500</param> </result> </action> Then on the JavaScript side you need to check the xmlHttpRequest.status field to see what you need to do, 200 means everything went fine; 401 means authorization required, which allows me to do whatever is appropriate for the specific request, which is typically to redirect the user to the login page, but in a timer situation, I can just ignore it or stop the timer; 500 means bad things happened on the server side and I might want to inform the user. (*Chris*) On Thu, Jan 27, 2011 at 7:09 PM, Dave Newton <davelnew...@gmail.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
