You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by chedana jayasinghe <ch...@gmail.com> on 2015/06/23 05:09:06 UTC
the session tracking of tomcat 6 and tomcat 7 behaves strangely
In my web application, in a jsp there is a javascript which sends request
to a servlet every twenty seconds, so it kills my applications user idle
time tracking by resetting the lastAccessed time in session. the funny
thing is lastAccessed time doesn't get updated in tomcat 6 and my
applications idle time tracking works fine in it, but in 7 it gets updated
and kills that functionality of the application . so I'm little bit
confused about the changes in the session tracking of tomcat 6 and tomcat
7.
Re: the session tracking of tomcat 6 and tomcat 7 behaves strangely
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Tim,
On 6/24/15 7:15 AM, Tim Watts wrote:
> On Wed, 2015-06-24 at 11:55 +0200, André Warnier wrote:
>> Hi.
>>
>> Hi.
>>
>> The recommendation on this forum is to not use "top posting", but
>> to keep the flow of conversation natural, and respond below the
>> question to which your question refers. See
>> http://tomcat.apache.org/lists.html, "Important", 6) I have
>> modified you latest post accordingly below.
>>
>> chedana jayasinghe wrote:
>>> On Tue, Jun 23, 2015 at 2:46 PM, André Warnier <aw...@ice-sa.com>
>>> wrote:
>>>
>>>> chedana jayasinghe wrote:
>>>>
>>>>> In my web application, in a jsp there is a javascript which
>>>>> sends request to a servlet every twenty seconds, so it
>>>>> kills my applications user idle time tracking by resetting
>>>>> the lastAccessed time in session. the funny thing is
>>>>> lastAccessed time doesn't get updated in tomcat 6 and my
>>>>> applications idle time tracking works fine in it, but in 7
>>>>> it gets updated and kills that functionality of the
>>>>> application . so I'm little bit confused about the changes
>>>>> in the session tracking of tomcat 6 and tomcat 7.
>>>>>
>>>>>
>>>> I don't know what happened in Tomcat 6 as compared to what
>>>> happens in other versions. But from a purely logical point of
>>>> view, I would tend to think that, from the server point of
>>>> view, whether a request comes from the user pressing a button
>>>> or from a javascript module in a page sending a request, does
>>>> not make a difference : the application has been accessed, so
>>>> the "last accessed time" should be updated. That is probably
>>>> the point even, of many such javascript snippets out there in
>>>> the wild.
>>>>
>>>> So again from a purely logical point of view, if Tomcat 6
>>>> then did not update the last access time, that would sound
>>>> more like a bug, that was corrected later.
>>>>
>>>> Maybe the fact that it updates this or not, depends on
>>>> whether the application that is called retrieves the session
>>>> or not, and if so you may have control over it, by making
>>>> sure that whatever your javascript calls, it does /not/
>>>> retrieve the session.
>>>>
>>>> Caveat : I do not really /know/ how it works, so there is a
>>>> lot of speculation here.
>>>>
>>
>>> I just put a debug point an checked. In tomcat 6,the request
>>> comes to the servlet with a null session,but in tomcat 7 and
>>> later versions the valid session is there in the request
>>>
>>
>> Yes, but the /call/ that contains this jsession-id, comes from
>> the javascript that is in the HTML page currently shown in the
>> browser. So the question is : why does that /call/, now, contain
>> this jsessionid parameter, when under Tomcat 6 it did not ?
>>
>> Or to put this another way : how does the local javascript in the
>> browser *know* this jsession-id ?
>>
>> Or in yet another way : the javascript in the browser does not
>> /know/ if it is talking to a Tomcat 6 or a Tomcat 7 or a Tomcat 8
>> server, right ? So how comes that in one case, it sends a request
>> /without/ a jsessionid, and in the other cases /with/ a
>> jsessionid ?
>>
> Haven't been following this thread too closely, so ignore this if
> it's a total non sequitur, but perhaps TC6 does NOT mark the
> cookie as HttpOnly while later versions do?
That might made sense if this was working as expected in Tomcat 7 but
not Tomcat 6, but it's the other way around.
I'm thinking something else is going on... it's tough to get responses
from the OP, but they keep posting new threads just in case someone
else wants to give it a try...
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVir+pAAoJEBzwKT+lPKRYAyEP/3GMWH86+pm1n9uSlSNdzTZ6
MkU4g5cyaIBrYiz2KAGJaaQgJZ0dOCYWjMF68MG40g4NmRK6OcJmAGYK2fl7Co0x
9INFrGk8sMhlcs5ssiijk5AF+d3B/9eZRYoX2YFTWzlSxL8Tttz/LDN6pjx3m1Am
6u9soq0zrIoOpsMLelfQtCBAUgjqtUOIlgG/8+3ufxbvJizhLq4QzQ49rzYzfizc
HkoorxzeSbwFaIzl2Gqnm2NcBg/lHM85mxRL8aIcK2yHIoMoHYqu6J24U353uOzM
YK0pZypZXDveOfvmWrK01NPYGMLK1IhTR/vB+TwjbZQeVtg25H/xFttXq4NsOBlR
EZgEbrma4pNlHofXVLL8sC/y/SSl7H/7MmRvVmJNG96gHmqN1SnaOoNprwtB24lY
IZN4flZ9Ur3tblW2PE/xVlWTn6bcirheTopne56lpQUbc8ff2s2tRajcBpCsjL+e
GgDjRG6lpigfOGPZKZ3lILWEtzytQXz+VPfEdHjFoaH0pIFOXPYFoTocopnrFHwz
zTZ0RK7Uda0FY56KHPEBljhmOHnn1CzcMY/VGISLC61FpGadL7hmvwppuFIoMIZQ
I5Ouu3kq2/vrMmOlfLnttWl9T2jP/4PBE36H7oMrboDDA5CJrrV2qo01tD3m8ghR
mN3TxA/TKKTVxqTp8lWT
=u+vX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: the session tracking of tomcat 6 and tomcat 7 behaves strangely
Posted by Tim Watts <ti...@cliftonfarm.org>.
On Wed, 2015-06-24 at 11:55 +0200, André Warnier wrote:
> Hi.
>
> Hi.
>
> The recommendation on this forum is to not use "top posting", but to keep the flow of
> conversation natural, and respond below the question to which your question refers.
> See http://tomcat.apache.org/lists.html, "Important", 6)
> I have modified you latest post accordingly below.
>
> chedana jayasinghe wrote:
> > On Tue, Jun 23, 2015 at 2:46 PM, André Warnier <aw...@ice-sa.com> wrote:
> >
> >> chedana jayasinghe wrote:
> >>
> >>> In my web application, in a jsp there is a javascript which sends request
> >>> to a servlet every twenty seconds, so it kills my applications user idle
> >>> time tracking by resetting the lastAccessed time in session. the funny
> >>> thing is lastAccessed time doesn't get updated in tomcat 6 and my
> >>> applications idle time tracking works fine in it, but in 7 it gets updated
> >>> and kills that functionality of the application . so I'm little bit
> >>> confused about the changes in the session tracking of tomcat 6 and tomcat
> >>> 7.
> >>>
> >>>
> >> I don't know what happened in Tomcat 6 as compared to what happens in
> >> other versions.
> >> But from a purely logical point of view, I would tend to think that, from
> >> the server point of view, whether a request comes from the user pressing a
> >> button or from a javascript module in a page sending a request, does not
> >> make a difference : the application has been accessed, so the "last
> >> accessed time" should be updated.
> >> That is probably the point even, of many such javascript snippets out
> >> there in the wild.
> >>
> >> So again from a purely logical point of view, if Tomcat 6 then did not
> >> update the last access time, that would sound more like a bug, that was
> >> corrected later.
> >>
> >> Maybe the fact that it updates this or not, depends on whether the
> >> application that is called retrieves the session or not, and if so you may
> >> have control over it, by making sure that whatever your javascript calls,
> >> it does /not/ retrieve the session.
> >>
> >> Caveat : I do not really /know/ how it works, so there is a lot of
> >> speculation here.
> >>
>
> > I just put a debug point an checked. In tomcat 6,the request comes to the
> > servlet with a null session,but in tomcat 7 and later versions the valid
> > session is there in the request
> >
>
> Yes, but the /call/ that contains this jsession-id, comes from the javascript that is in
> the HTML page currently shown in the browser.
> So the question is : why does that /call/, now, contain this jsessionid parameter, when
> under Tomcat 6 it did not ?
>
> Or to put this another way : how does the local javascript in the browser *know* this
> jsession-id ?
>
> Or in yet another way : the javascript in the browser does not /know/ if it is talking to
> a Tomcat 6 or a Tomcat 7 or a Tomcat 8 server, right ? So how comes that in one case, it
> sends a request /without/ a jsessionid, and in the other cases /with/ a jsessionid ?
>
Haven't been following this thread too closely, so ignore this if it's a
total non sequitur, but perhaps TC6 does NOT mark the cookie as
HttpOnly while later versions do?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: the session tracking of tomcat 6 and tomcat 7 behaves strangely
Posted by André Warnier <aw...@ice-sa.com>.
Hi.
Hi.
The recommendation on this forum is to not use "top posting", but to keep the flow of
conversation natural, and respond below the question to which your question refers.
See http://tomcat.apache.org/lists.html, "Important", 6)
I have modified you latest post accordingly below.
chedana jayasinghe wrote:
> On Tue, Jun 23, 2015 at 2:46 PM, André Warnier <aw...@ice-sa.com> wrote:
>
>> chedana jayasinghe wrote:
>>
>>> In my web application, in a jsp there is a javascript which sends request
>>> to a servlet every twenty seconds, so it kills my applications user idle
>>> time tracking by resetting the lastAccessed time in session. the funny
>>> thing is lastAccessed time doesn't get updated in tomcat 6 and my
>>> applications idle time tracking works fine in it, but in 7 it gets updated
>>> and kills that functionality of the application . so I'm little bit
>>> confused about the changes in the session tracking of tomcat 6 and tomcat
>>> 7.
>>>
>>>
>> I don't know what happened in Tomcat 6 as compared to what happens in
>> other versions.
>> But from a purely logical point of view, I would tend to think that, from
>> the server point of view, whether a request comes from the user pressing a
>> button or from a javascript module in a page sending a request, does not
>> make a difference : the application has been accessed, so the "last
>> accessed time" should be updated.
>> That is probably the point even, of many such javascript snippets out
>> there in the wild.
>>
>> So again from a purely logical point of view, if Tomcat 6 then did not
>> update the last access time, that would sound more like a bug, that was
>> corrected later.
>>
>> Maybe the fact that it updates this or not, depends on whether the
>> application that is called retrieves the session or not, and if so you may
>> have control over it, by making sure that whatever your javascript calls,
>> it does /not/ retrieve the session.
>>
>> Caveat : I do not really /know/ how it works, so there is a lot of
>> speculation here.
>>
> I just put a debug point an checked. In tomcat 6,the request comes to the
> servlet with a null session,but in tomcat 7 and later versions the valid
> session is there in the request
>
Yes, but the /call/ that contains this jsession-id, comes from the javascript that is in
the HTML page currently shown in the browser.
So the question is : why does that /call/, now, contain this jsessionid parameter, when
under Tomcat 6 it did not ?
Or to put this another way : how does the local javascript in the browser *know* this
jsession-id ?
Or in yet another way : the javascript in the browser does not /know/ if it is talking to
a Tomcat 6 or a Tomcat 7 or a Tomcat 8 server, right ? So how comes that in one case, it
sends a request /without/ a jsessionid, and in the other cases /with/ a jsessionid ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: the session tracking of tomcat 6 and tomcat 7 behaves strangely
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Chedana,
On 6/23/15 10:40 AM, chedana jayasinghe wrote:
> I just put a debug point an checked. In tomcat 6,the request comes
> to the servlet with a null session,but in tomcat 7 and later
> versions the valid session is there in the request
When you say "the session is there in the request", do you mean that
calling request.getSession(false) returns something non-null?
Something must be tripping the loading of the session, which is why I
was asking last week about using "Strict servlet compliance", because
that will always update the last-touched-time of the session even if
they web application doesn't try to access the session.
Have *anything else* changed?
Can you create a Filter that wraps the request and reports all calls
to getSession(boolean) to a log file? If you can't catch it there, you
might have to write a Valve to catch it at a lower level (so you can
see if Tomcat itself is accessing the session).
- -chris
> On Tue, Jun 23, 2015 at 2:46 PM, André Warnier <aw...@ice-sa.com>
> wrote:
>
>> chedana jayasinghe wrote:
>>
>>> In my web application, in a jsp there is a javascript which
>>> sends request to a servlet every twenty seconds, so it kills my
>>> applications user idle time tracking by resetting the
>>> lastAccessed time in session. the funny thing is lastAccessed
>>> time doesn't get updated in tomcat 6 and my applications idle
>>> time tracking works fine in it, but in 7 it gets updated and
>>> kills that functionality of the application . so I'm little
>>> bit confused about the changes in the session tracking of
>>> tomcat 6 and tomcat 7.
>>>
>>>
>> I don't know what happened in Tomcat 6 as compared to what
>> happens in other versions. But from a purely logical point of
>> view, I would tend to think that, from the server point of view,
>> whether a request comes from the user pressing a button or from a
>> javascript module in a page sending a request, does not make a
>> difference : the application has been accessed, so the "last
>> accessed time" should be updated. That is probably the point
>> even, of many such javascript snippets out there in the wild.
>>
>> So again from a purely logical point of view, if Tomcat 6 then
>> did not update the last access time, that would sound more like a
>> bug, that was corrected later.
>>
>> Maybe the fact that it updates this or not, depends on whether
>> the application that is called retrieves the session or not, and
>> if so you may have control over it, by making sure that whatever
>> your javascript calls, it does /not/ retrieve the session.
>>
>> Caveat : I do not really /know/ how it works, so there is a lot
>> of speculation here.
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJViYGXAAoJEBzwKT+lPKRYZ08P/3tWuZ0oQuntLFCWWNyS1DPf
vr+cpisBd0CIMRPgJYvLu28ocrsb1piCdoXK1GaLmwduyjQPlXcoxRRelfUTkjmj
adxN/NTQVi6k3NOVd80dpPfYu0gFeZ0GhYXp5tJnuchBrRLcwITVbrV9OZ0BXCgK
Pu9jWiH53GZGWyFRv3eeX3QdYi9a3IH438sX1lBfhDyQcqlAPvtaq9Uc961/ypcj
9yu5exlOQU6hzlHNGNnjhcS1JSq1+sJ4sF8WCyIsV28orXtmHLLv3SgOgM4XniR9
hHDVffXuap8l9U2pf0EGOoAfNhd5Eim8uqhrUPLuKA55u9c1IlRQ7abYUML4AOWt
SikPikd/9lvv4HPujE2jV/xl6fRlEMetGtckQRHrlgorMNDvO/OUSZNVfEW/9PgR
8/qagq+Wew4bQPWfsWDkE3ZfN1YD2HWx4f35ErEZFY5NgxXjMGDNoRmD9aXSLf5m
mpFqp5NL7Vy+3tNjTAaEVdK3n60Xhko2WQlaH65A+8dSbJD4giVY01HSYGvzF7H6
Uth0N2ij6wJ3VL8bZdezsHZhgrQ0OMWGl6AtqDcjsPgtDFOY43uG5AlG5dITjLyX
MO41HhjL0WO+gC4aI2k+ksoNNspYYzzoOT2ccQAKhpPUieRTj41efmJqWLP2tkQM
bYGEYdD4zvwfdLDqaPu8
=PUtU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: the session tracking of tomcat 6 and tomcat 7 behaves strangely
Posted by chedana jayasinghe <ch...@gmail.com>.
I just put a debug point an checked. In tomcat 6,the request comes to the
servlet with a null session,but in tomcat 7 and later versions the valid
session is there in the request
On Tue, Jun 23, 2015 at 2:46 PM, André Warnier <aw...@ice-sa.com> wrote:
> chedana jayasinghe wrote:
>
>> In my web application, in a jsp there is a javascript which sends request
>> to a servlet every twenty seconds, so it kills my applications user idle
>> time tracking by resetting the lastAccessed time in session. the funny
>> thing is lastAccessed time doesn't get updated in tomcat 6 and my
>> applications idle time tracking works fine in it, but in 7 it gets updated
>> and kills that functionality of the application . so I'm little bit
>> confused about the changes in the session tracking of tomcat 6 and tomcat
>> 7.
>>
>>
> I don't know what happened in Tomcat 6 as compared to what happens in
> other versions.
> But from a purely logical point of view, I would tend to think that, from
> the server point of view, whether a request comes from the user pressing a
> button or from a javascript module in a page sending a request, does not
> make a difference : the application has been accessed, so the "last
> accessed time" should be updated.
> That is probably the point even, of many such javascript snippets out
> there in the wild.
>
> So again from a purely logical point of view, if Tomcat 6 then did not
> update the last access time, that would sound more like a bug, that was
> corrected later.
>
> Maybe the fact that it updates this or not, depends on whether the
> application that is called retrieves the session or not, and if so you may
> have control over it, by making sure that whatever your javascript calls,
> it does /not/ retrieve the session.
>
> Caveat : I do not really /know/ how it works, so there is a lot of
> speculation here.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: the session tracking of tomcat 6 and tomcat 7 behaves strangely
Posted by André Warnier <aw...@ice-sa.com>.
chedana jayasinghe wrote:
> In my web application, in a jsp there is a javascript which sends request
> to a servlet every twenty seconds, so it kills my applications user idle
> time tracking by resetting the lastAccessed time in session. the funny
> thing is lastAccessed time doesn't get updated in tomcat 6 and my
> applications idle time tracking works fine in it, but in 7 it gets updated
> and kills that functionality of the application . so I'm little bit
> confused about the changes in the session tracking of tomcat 6 and tomcat
> 7.
>
I don't know what happened in Tomcat 6 as compared to what happens in other versions.
But from a purely logical point of view, I would tend to think that, from the server point
of view, whether a request comes from the user pressing a button or from a javascript
module in a page sending a request, does not make a difference : the application has been
accessed, so the "last accessed time" should be updated.
That is probably the point even, of many such javascript snippets out there in the wild.
So again from a purely logical point of view, if Tomcat 6 then did not update the last
access time, that would sound more like a bug, that was corrected later.
Maybe the fact that it updates this or not, depends on whether the application that is
called retrieves the session or not, and if so you may have control over it, by making
sure that whatever your javascript calls, it does /not/ retrieve the session.
Caveat : I do not really /know/ how it works, so there is a lot of speculation here.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org