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
|