Re: Session expiration and AJAX issues

2008-02-26 Thread Adam Gordon

Not easily.  See Christopher's response in this thread chain.  There is
not currently a way to not tell Tomcat that a request has come in and
not update the last ping time (or similar) on the Session.


Jason Pyeron wrote:
 

  

-Original Message-
From: Adam Gordon [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 25, 2008 13:11

To: Tomcat Users List
Subject: Re: Session expiration and AJAX issues

Martin-

We are using Struts, however, version 1.2.9.  But, after 
looking at the 
link, I'm not sure this will help as it doesn't really address the 
problem.  Storing the date/time a user logs in on the session is 
probably useful, but our problem is that we want to 
forcefully log the 
user out if there's no human present at the computer and the 
AJAX tasks 
keep a user's session active indefinitely, whether or not 
they mean it to.



Can url patterns be excluded from session prolonging magic?

  
Additionally, assuming we didn't have the AJAX tasks, we'd 
have to check 
the logged in time from the session on every request and 
that's just not 
realistic when you have hundreds of Struts actions, even with 
a unique 
parent Action class.  That said, I'm beginning to suspect 
that this may 
be the only way to go, i.e., have  base Action for Struts actions and 
base action for AJAX actions.  My only issue with this is 
that then the 
onus is on the developer to use the right Action and if they don't, a 
session could inadvertently be left open which is a security risk.


Alternatively, we could simply force the logout on the user after 12 
hours period...which would kind of suck for the user if they 
were in the 
middle of something and so I can almost guarantee that our product 
management team wouldn't go for it since it's not really creating a 
positive user experience.


--adam





-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Session expiration and AJAX issues

2008-02-25 Thread Bob Hall

--- 2:09PM Mon 25 Feb 2008 Adam Gordon
<[EMAIL PROTECTED]> wrote:

> Adding a time decay in our timer task is an
> interesting idea and were it 
> not for IE's JavaScript counting ineptness, that'd
> probably work.
> 

The server could track the requests and provide an
updated delay time for the timer task if the browser
isn't reliable.

-Bob


  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Session expiration and AJAX issues

2008-02-25 Thread mgainty
Jason-

the url patterns depends on the servlet mapping you've defined..

You're going to need some algorithm which defines infinity
Your current mechanism binds the current Servlet to the ajax control (div?)
Acquire the initial date/time ..store it somewhere..hopeully in session
when the servlet finally reaches delta greater than *some predefined
infinite value* send back result which will cause
either the innerhtml to have the requisite logout.jsp or path to logout.jsp
return some predefined ActionResult which will *map* to your logout.jsp

M-
- Original Message -
Wrom: FVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLV
To: "'Tomcat Users List'" 
Sent: Monday, February 25, 2008 2:29 PM
Subject: RE: Session expiration and AJAX issues


>
>
> > -Original Message-
> > Wrom: LMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHM
> > Sent: Monday, February 25, 2008 13:11
> > To: Tomcat Users List
> > Subject: Re: Session expiration and AJAX issues
> >
> > Martin-
> >
> > We are using Struts, however, version 1.2.9.  But, after
> > looking at the
> > link, I'm not sure this will help as it doesn't really address the
> > problem.  Storing the date/time a user logs in on the session is
> > probably useful, but our problem is that we want to
> > forcefully log the
> > user out if there's no human present at the computer and the
> > AJAX tasks
> > keep a user's session active indefinitely, whether or not
> > they mean it to.
>
>
>
>
>
> Can url patterns be excluded from session prolonging magic?
>
>
>
>
>
> >
> > Additionally, assuming we didn't have the AJAX tasks, we'd
> > have to check
> > the logged in time from the session on every request and
> > that's just not
> > realistic when you have hundreds of Struts actions, even with
> > a unique
> > parent Action class.  That said, I'm beginning to suspect
> > that this may
> > be the only way to go, i.e., have  base Action for Struts actions and
> > base action for AJAX actions.  My only issue with this is
> > that then the
> > onus is on the developer to use the right Action and if they don't, a
> > session could inadvertently be left open which is a security risk.
> >
> > Alternatively, we could simply force the logout on the user after 12
> > hours period...which would kind of suck for the user if they
> > were in the
> > middle of something and so I can almost guarantee that our product
> > management team wouldn't go for it since it's not really creating a
> > positive user experience.
> >
> > --adam
> >
> > Martin Gainty wrote:
> > > Hi Adam-
> > >
> > > You can try this with Struts..
> > > http://struts.apache.org/2.x/docs/simplelogin-with-session.html
> > > insert the starting-date-time intio Session variable
> > > and then in the logoutAction.execute method do some quick
> > math on the
> > > time-delta to determine if you want to quiesce the session
> > >
> > > HTH
> > > M-
> > >
> > > - Original Message -
> > > Wrom: KHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONE
> > > To: "Tomcat Users List" 
> > > Sent: Monday, February 25, 2008 11:04 AM
> > > Subject: Session expiration and AJAX issues
> > >
> > >
> > >
> > >> A couple of issues:
> > >>
> > >> We've set our session expiration to 12 hours (I know it's long) and
> > >> we're seeing behavior where certain browsers (namely IE) apparently
> > >> can't count that high (we set the meta Refresh header but the page
> > >> doesn't reload after the allotted time, session expiration
> > time + 20
> > >> minutes).
> > >>
> > >> Since this issue was discovered, we've added background
> > AJAX timers on
> > >> some of our web pages that refresh (authenticated)
> > content.  While this
> > >> happily works, unfortunately, if the user chooses to
> > remain on one of
> > >> these pages, and then goes on vacation, the session stays
> > active because
> > >> the AJAX calls keep the session alive.
> > >>
> > >> Our first attempt at a solution was to have a JavaScript
> > counter that,
> > >> after every 20 minutes, incremented a counter and if that
> > counter ever
> > >> got to 37, we knew that the user hadn't changed web pages
> > and we could
> > >> log them out (wi

Re: Session expiration and AJAX issues

2008-02-25 Thread Adam Gordon
Adding a time decay in our timer task is an interesting idea and were it 
not for IE's JavaScript counting ineptness, that'd probably work.


Bob Hall wrote:

--- 10:10AM Mon 25 Feb 2008, Adam Gordon
<[EMAIL PROTECTED]> wrote:

  

Storing the date/time a user logs in on
the session is 
probably useful, but our problem is that we want to
forcefully log the 
user out if there's no human present at the computer
and the AJAX tasks 
keep a user's session active indefinitely, whether

or not they mean it to.




If there's a user input side to the AJAX tasks, would
it be possible for the AJAX task time interval to
increase over time w/o user input? Eventually, this
would lead to a session timeout.

-Bob


  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Session expiration and AJAX issues

2008-02-25 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Adam,

What you need is to make a request without "touching" the session.
Tomcat cannot do this by itself; you're going to have to either hack
Tomcat to add a "no-touch-session" parameter to the session manager
(which wouldn't be a bad TC enhancement request, actually), or pass your
session information in a different way through your AJAX calls (say,
using "mysessionid" as a request parameter, and be sure that the
JSESSIONID cookie is /not/ sent - which might be quite difficult).

The second option is rife with complexity, because then you need to have
your server-side AJAX stuff take the session id and look it up in a
self-managed cache of sessions (see HttpSessionListener), etc., etc., etc.

Here's another option that might not be /quite/ as nasty, but it's still
a pretty bad hack:

1. Invent a new request parameter called "noTouchSession" and add
~   &noTouchSession=true to all of your AJAX calls.

2. Write a Filter that looks something like this:

public void doFilter(ServletRequest req, ServletResponse resp,
FilterChain chain)
{
~HttpServletRequest hReq = (HttpServletRequest)req;

~HttpSession session = hReq.getSession(false);
~if(null != session)
~{
~Date expirationDate =
~ (Date)session.getAttribute("expirationDate");

~if(expirationDate.before(new Date())
~{
~// probably want to log this event
~session.invalidate();
~session=null;
~}
~else
~{

~if("true".equalsIgnoreCase(hReq.getParameter("noTouchSession")))
~{
~// Do nothing; don't update the session timestamp
~}
~else
~{
~session.setAttribute("expirationDate",
~   new Date(System.currentTimeMillis() +
~session.getMaxInactiveInterval() / 1000));
~}

~}
~}

~chain.doFilter(req, resp);
}

What this will do is essentially simulate session timeouts using an
attribute /you/ store in the session instead of relying on the
container. The container will still do all the real work of session
management, which is nice.

Since your AJAX requests will add the magic parameter that doesn't touch
the session timeout, your session will eventually time out (using this
mechanism, not that of the container).

Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkfDJY0ACgkQ9CaO5/Lv0PB/7gCdFap7ZW3RZNxrlewwBmtNtwpH
Yr0AoKdYyaGjZkWzUtORawePA+xOFTlX
=uSL3
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Session expiration and AJAX issues

2008-02-25 Thread Jason Pyeron
 

> -Original Message-
> From: Adam Gordon [mailto:[EMAIL PROTECTED] 
> Sent: Monday, February 25, 2008 13:11
> To: Tomcat Users List
> Subject: Re: Session expiration and AJAX issues
> 
> Martin-
> 
> We are using Struts, however, version 1.2.9.  But, after 
> looking at the 
> link, I'm not sure this will help as it doesn't really address the 
> problem.  Storing the date/time a user logs in on the session is 
> probably useful, but our problem is that we want to 
> forcefully log the 
> user out if there's no human present at the computer and the 
> AJAX tasks 
> keep a user's session active indefinitely, whether or not 
> they mean it to.





Can url patterns be excluded from session prolonging magic?





> 
> Additionally, assuming we didn't have the AJAX tasks, we'd 
> have to check 
> the logged in time from the session on every request and 
> that's just not 
> realistic when you have hundreds of Struts actions, even with 
> a unique 
> parent Action class.  That said, I'm beginning to suspect 
> that this may 
> be the only way to go, i.e., have  base Action for Struts actions and 
> base action for AJAX actions.  My only issue with this is 
> that then the 
> onus is on the developer to use the right Action and if they don't, a 
> session could inadvertently be left open which is a security risk.
> 
> Alternatively, we could simply force the logout on the user after 12 
> hours period...which would kind of suck for the user if they 
> were in the 
> middle of something and so I can almost guarantee that our product 
> management team wouldn't go for it since it's not really creating a 
> positive user experience.
> 
> --adam
> 
> Martin Gainty wrote:
> > Hi Adam-
> >
> > You can try this with Struts..
> > http://struts.apache.org/2.x/docs/simplelogin-with-session.html
> > insert the starting-date-time intio Session variable
> > and then in the logoutAction.execute method do some quick 
> math on the
> > time-delta to determine if you want to quiesce the session
> >
> > HTH
> > M-
> >
> > - Original Message -
> > From: "Adam Gordon" <[EMAIL PROTECTED]>
> > To: "Tomcat Users List" 
> > Sent: Monday, February 25, 2008 11:04 AM
> > Subject: Session expiration and AJAX issues
> >
> >
> >   
> >> A couple of issues:
> >>
> >> We've set our session expiration to 12 hours (I know it's long) and
> >> we're seeing behavior where certain browsers (namely IE) apparently
> >> can't count that high (we set the meta Refresh header but the page
> >> doesn't reload after the allotted time, session expiration 
> time + 20
> >> minutes).
> >>
> >> Since this issue was discovered, we've added background 
> AJAX timers on
> >> some of our web pages that refresh (authenticated) 
> content.  While this
> >> happily works, unfortunately, if the user chooses to 
> remain on one of
> >> these pages, and then goes on vacation, the session stays 
> active because
> >> the AJAX calls keep the session alive.
> >>
> >> Our first attempt at a solution was to have a JavaScript 
> counter that,
> >> after every 20 minutes, incremented a counter and if that 
> counter ever
> >> got to 37, we knew that the user hadn't changed web pages 
> and we could
> >> log them out (window.location = .  The problem 
> is that this
> >> doesn't appear to work either and additionally, it relies 
> on JavaScript
> >> bypassing Tomcat's built-in features.  User's cannot log 
> in w/o having
> >> JavaScript enabled, so it's not a matter of a user 
> potentially disabling
> >> it, rather it puts the onus on the browser to inform the 
> server that the
> >> user's session needs to be expired.
> >>
> >> Does anyone have experience in this area and if so, how 
> have you solved
> >> this problem?  I know Google uses AJAX with their Gmail 
> webapp, but they
> >> don't seem to care about not expiring the user's session.  Any help
> >> would be appreciated.
> >>
> >> Thanks,
> >>
> >> --adam
> >>
> >> 
> -
> >> To start a new topic, e-mail: users@tomcat.apache.org
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >&g

Re: Session expiration and AJAX issues

2008-02-25 Thread Bob Hall

--- 10:10AM Mon 25 Feb 2008, Adam Gordon
<[EMAIL PROTECTED]> wrote:

> Storing the date/time a user logs in on
> the session is 
> probably useful, but our problem is that we want to
> forcefully log the 
> user out if there's no human present at the computer
> and the AJAX tasks 
> keep a user's session active indefinitely, whether
> or not they mean it to.
> 

If there's a user input side to the AJAX tasks, would
it be possible for the AJAX task time interval to
increase over time w/o user input? Eventually, this
would lead to a session timeout.

-Bob


  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Session expiration and AJAX issues

2008-02-25 Thread Adam Gordon

Martin-

We are using Struts, however, version 1.2.9.  But, after looking at the 
link, I'm not sure this will help as it doesn't really address the 
problem.  Storing the date/time a user logs in on the session is 
probably useful, but our problem is that we want to forcefully log the 
user out if there's no human present at the computer and the AJAX tasks 
keep a user's session active indefinitely, whether or not they mean it to.


Additionally, assuming we didn't have the AJAX tasks, we'd have to check 
the logged in time from the session on every request and that's just not 
realistic when you have hundreds of Struts actions, even with a unique 
parent Action class.  That said, I'm beginning to suspect that this may 
be the only way to go, i.e., have  base Action for Struts actions and 
base action for AJAX actions.  My only issue with this is that then the 
onus is on the developer to use the right Action and if they don't, a 
session could inadvertently be left open which is a security risk.


Alternatively, we could simply force the logout on the user after 12 
hours period...which would kind of suck for the user if they were in the 
middle of something and so I can almost guarantee that our product 
management team wouldn't go for it since it's not really creating a 
positive user experience.


--adam

Martin Gainty wrote:

Hi Adam-

You can try this with Struts..
http://struts.apache.org/2.x/docs/simplelogin-with-session.html
insert the starting-date-time intio Session variable
and then in the logoutAction.execute method do some quick math on the
time-delta to determine if you want to quiesce the session

HTH
M-

- Original Message -
From: "Adam Gordon" <[EMAIL PROTECTED]>
To: "Tomcat Users List" 
Sent: Monday, February 25, 2008 11:04 AM
Subject: Session expiration and AJAX issues


  

A couple of issues:

We've set our session expiration to 12 hours (I know it's long) and
we're seeing behavior where certain browsers (namely IE) apparently
can't count that high (we set the meta Refresh header but the page
doesn't reload after the allotted time, session expiration time + 20
minutes).

Since this issue was discovered, we've added background AJAX timers on
some of our web pages that refresh (authenticated) content.  While this
happily works, unfortunately, if the user chooses to remain on one of
these pages, and then goes on vacation, the session stays active because
the AJAX calls keep the session alive.

Our first attempt at a solution was to have a JavaScript counter that,
after every 20 minutes, incremented a counter and if that counter ever
got to 37, we knew that the user hadn't changed web pages and we could
log them out (window.location = .  The problem is that this
doesn't appear to work either and additionally, it relies on JavaScript
bypassing Tomcat's built-in features.  User's cannot log in w/o having
JavaScript enabled, so it's not a matter of a user potentially disabling
it, rather it puts the onus on the browser to inform the server that the
user's session needs to be expired.

Does anyone have experience in this area and if so, how have you solved
this problem?  I know Google uses AJAX with their Gmail webapp, but they
don't seem to care about not expiring the user's session.  Any help
would be appreciated.

Thanks,

--adam

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





  


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Session expiration and AJAX issues

2008-02-25 Thread Adam Gordon

Paul-

> Are you saying that certain browser will never expire their sessions?
> Or are you saying that certain browsers kill their sessions before 12
> hours (because they can't count that high)?

The former, i.e. that browsers will never expire the sessions.

> The way I understand it - you are using ajax to keep a session alive.
> Why not set the session expiration to live as long as the browser is
> open, or for some other length of time? The session mechanism should
> work. I don't understand the need to hack sessions using ajax.

As indicated from the tone of my original post (see the second sentence 
of the second paragraph in my original post), are not intentionally 
using AJAX to keep the session alive - it is a side-effect which we 
would like to obviate, hence the JavaScript counter.


> Isn't that part of the browser's job?

Uh, I would have to argue that this is a HUGE no.  I think it's VERY 
obvious to anyone that has done any sort of web development with 
cross-browser compatibility in mind that browser makers cannot be relied 
upon to implement ANY sort of common standard in the same way (case and 
point look at how you instantiate an XmlHttpRequest object in JavaScript 
across different browsers, not to mention CSS functionality).  Besides 
if it were the browser's job, why would Tomcat even have support for 
it?  It's like making an assumption that user's never leave their 
browsers open or never click the back button.  I think the only thing 
one can absolutely rely on a user doing in a web application using it in 
a manner to which one had not considered.


So, all that said, is there anyone out there who's had experience with 
this problem and knows of a solution?  Thanks.


--adam

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Session expiration and AJAX issues

2008-02-25 Thread Paul Simon
Hi,

> We've set our session expiration to 12 hours (I know it's long) and 
> we're seeing behavior where certain browsers (namely IE) apparently 
> can't count that high (we set the meta Refresh header but the page 
> doesn't reload after the allotted time, session expiration time + 20 
> minutes).

Are you saying that certain browser will never expire their sessions? Or are 
you saying that certain browsers kill their sessions before 12 hours (because 
they can't count that high)?

> Since this issue was discovered, we've added background AJAX timers on 
> some of our web pages that refresh (authenticated) content.  While this 
> happily works, unfortunately, if the user chooses to remain on one of 
> these pages, and then goes on vacation, the session stays active because 
> the AJAX calls keep the session alive.

The way I understand it - you are using ajax to keep a session alive. Why not 
set the session expiration to live as long as the browser is open, or for some 
other length of time? The session mechanism should work. I don't understand the 
need to hack sessions using ajax.

> it puts the onus on the browser to inform the server that the 
> user's session needs to be expired.

Isn't that part of the browser's job?

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Session expiration and AJAX issues

2008-02-25 Thread Adam Gordon

A couple of issues:

We've set our session expiration to 12 hours (I know it's long) and 
we're seeing behavior where certain browsers (namely IE) apparently 
can't count that high (we set the meta Refresh header but the page 
doesn't reload after the allotted time, session expiration time + 20 
minutes).


Since this issue was discovered, we've added background AJAX timers on 
some of our web pages that refresh (authenticated) content.  While this 
happily works, unfortunately, if the user chooses to remain on one of 
these pages, and then goes on vacation, the session stays active because 
the AJAX calls keep the session alive.


Our first attempt at a solution was to have a JavaScript counter that, 
after every 20 minutes, incremented a counter and if that counter ever 
got to 37, we knew that the user hadn't changed web pages and we could 
log them out (window.location = .  The problem is that this 
doesn't appear to work either and additionally, it relies on JavaScript 
bypassing Tomcat's built-in features.  User's cannot log in w/o having 
JavaScript enabled, so it's not a matter of a user potentially disabling 
it, rather it puts the onus on the browser to inform the server that the 
user's session needs to be expired.


Does anyone have experience in this area and if so, how have you solved 
this problem?  I know Google uses AJAX with their Gmail webapp, but they 
don't seem to care about not expiring the user's session.  Any help 
would be appreciated.


Thanks,

--adam

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]