You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "CRANFORD, CHRIS" <Ch...@setech.com> on 2011/01/28 03:28:58 UTC
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
Re: AJAX & Sessions
Posted by Dale Newfield <da...@newfield.org>.
On 1/27/11 9:28 PM, CRANFORD, CHRIS wrote:
> 2. Does HttpSession contain value holding time of last User request?
> No -> Create one, store it in session, proceed
Shouldn't that "-> LOGIN" instead of "proceed"?
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: AJAX & Sessions
Posted by Steven Yang <ke...@gmail.com>.
Like Dave said
The way I did it is in the LoginInterceptor I check the header to see if its
an XHR (i have special header for all my XHR calls, I dunno any other way to
distinguish between normal http call and xhr, if anyone has better way
please do share), and if it is return a special header, then in my
javascript will just see if that special header exists. and if its normal
http call then just do redirect
On Fri, Jan 28, 2011 at 11:09 AM, Dave Newton <da...@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
> <Ch...@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
>
>
RE: AJAX & Sessions
Posted by "Biesbrock, Kevin" <Bi...@aoins.com>.
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 <da...@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
> <Ch...@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
Re: AJAX & Sessions
Posted by Chris Pratt <th...@gmail.com>.
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 <da...@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
> <Ch...@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
>
>
Re: AJAX & Sessions
Posted by Dave Newton <da...@gmail.com>.
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
<Ch...@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
RE: AJAX & Sessions
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
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
RE: AJAX & Sessions
Posted by Scott <st...@gmail.com>.
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