struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Biesbrock, Kevin" <Biesbrock.Ke...@aoins.com>
Subject RE: AJAX & Sessions
Date Fri, 28 Jan 2011 13:24:46 GMT
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:thechrispratt@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 <davelnewton@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.Cranford@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:stanlick@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.Cranford@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-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message