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
>
>
