You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by logo <lo...@kreuser.name> on 2020/05/02 13:58:46 UTC

Re: Losing session between calls from mobile phone

AJ

> Am 30.04.2020 um 22:22 schrieb AJ Chen <aj...@web2express.org>:
> 
> The session problem happens when testing without SSL.
> 
Just a thought:

If the session cookie has the secure flag it will not be sent on http requests. (That would fail your test above in any case!)

Now if that happens during regular https usage, it could be that one requests redirects to http. That will remove the cookie and a new session will be generated. The next https-request will have new cookie and then you start from scratch.


Could that be possible?

Peter


> I'll try to test with Tomcat session manager example app. Thanks, Chris.
> 
> -aj
> 
> On Wed, Apr 29, 2020 at 3:05 PM Christopher Schultz <
> chris@christopherschultz.net> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>> 
>> AJ,
>> 
>> On 4/29/20 13:46, AJ Chen wrote:
>>> On Wed, Apr 29, 2020 at 10:28 AM Christopher Schultz <
>>> chris@christopherschultz.net> wrote:
>>> 
>>> AJ,
>>> 
>>> On 4/29/20 13:24, AJ Chen wrote:
>>>>>> Chris, When i use my latest iphone 11 to access the web app,
>>>>>> tomcat server generates new session every time. It's normal
>>>>>> use, not private browsing.> I did not change any setting on
>>>>>> tomcat regarding session, use default session tracking. Is
>>>>>> there any setting that can enforce using previous session
>>>>>> (i.e. track session)?  Can I save the previous SessionID and
>>>>>> use it to get the session with this id explicitly?
>>> AFAIK, Safari Mobile doesn't do anything weird.
>>> 
>>> Are you always using TLS (HTTPS)?
>>> 
>>> -chris
>>> 
>>>>>> On Wed, Apr 29, 2020 at 10:13 AM Christopher Schultz <
>>>>>> chris@christopherschultz.net> wrote:
>>>>>> 
>>>>>> AJ,
>>>>>> 
>>>>>> On 4/28/20 16:13, AJ Chen wrote:
>>>>>>>>> Andre, thanks for asking the questions. Yes, we try to
>>>>>>>>> get understand the behaviors.
>>>>>>>>> 
>>>>>>>>> We have seen iphone and other android phones, on
>>>>>>>>> different carriers, from different networks, encounter
>>>>>>>>> this problem - losing session. It does not seem there
>>>>>>>>> is a pattern so far. Users use all kinds of phones.
>>>>>>>>> Some of their phones experience this problem.
>>>>>> 
>>>>>> Are any of them using "private browsing" or anything like
>>>>>> that?
>>>>>> 
>>>>>> Are you just using the standard Tomcat-generated JSESSIONID
>>>>>> cookies?
>>>>>> 
>>>>>> -chris
>>>>>> 
>>>>>>>>> On Tue, Apr 28, 2020 at 12:08 PM André Warnier
>>>>>>>>> (tomcat/perl) <aw...@ice-sa.com> wrote:
>>>>>>>>> 
>>>>>>>>>> On 28.04.2020 18:28, AJ Chen wrote:
>>>>>>>>>>> Thanks. Martin and Mark.
>>>>>>>>>>> 
>>>>>>>>>>> I can recreate the problem: I compare two
>>>>>>>>>>> different mobile phones. One phone can log in and
>>>>>>>>>>> proceed. Server log shows the same session persists
>>>>>>>>>>> (same sessionID upon different requests). The other
>>>>>>>>>>> phone can log in, but upon next request, server log
>>>>>>>>>>> show a new session is always created (new
>>>>>>>>>>> sessionId).
>>>>>>>>>>> 
>>>>>>>>>>> Since session tracking works on PC browser and
>>>>>>>>>>> some mobile phone, the
>>>>>>>>>> proxy
>>>>>>>>>>> (if any) in front of aws EC2 server should not be
>>>>>>>>>>> the problem.
>>>>>>>>>> Anything
>>>>>>>>>>> else may be missing?
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Asking just in case : - are the 2 phones on the same
>>>>>>>>>> network carrier ? - are they the same brand, or at
>>>>>>>>>> least OS ? - if you connect them both to the same
>>>>>>>>>> local WiFi, do they still act differently ?
>>>>>>>>>> 
>>>>>>>>>> Note : no idea if this makes any difference, but
>>>>>>>>>> we're trying to find a reason why they act
>>>>>>>>>> differently when using the same Internet application
>>>>>>>>>> server, right ?
>>>>>>>>>> 
>>>>>>>>>>> -aj
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Tue, Apr 28, 2020 at 12:30 AM Mark Thomas
>>>>>>>>>>> <ma...@apache.org> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> On 28/04/2020 07:47, Martin Grigorov wrote:
>>>>>>>>>>>>> On Tue, Apr 28, 2020 at 9:11 AM AJ Chen
>>>>>>>>>>>>> <aj...@web2express.org>
>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Anyway to fix it? thanks. -aj
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> First you need to investigate whether there is
>>>>>>>>>>>>> a proxy. Then what kind of proxy. Then where is
>>>>>>>>>>>>> its configuration. Then consult with its manual
>>>>>>>>>>>>> and see whether there is something
>>>>>>>>>>>>> wrong/missng.
>>>>>>>>>>>> 
>>>>>>>>>>>> I'd recommend taking a step back.
>>>>>>>>>>>> 
>>>>>>>>>>>> Guessing at what might be wrong and then trying
>>>>>>>>>>>> to fix the problem you have only guessed at is
>>>>>>>>>>>> unlikely to work.
>>>>>>>>>>>> 
>>>>>>>>>>>> Can you recreate the problem? You can't tell if
>>>>>>>>>>>> something is fixed if you can't recreate it.
>>>>>>>>>>>> 
>>>>>>>>>>>> Once you recreate the problem then you can start
>>>>>>>>>>>> to narrow it down. You need to track what is
>>>>>>>>>>>> happening to the session ID. You'll probably need
>>>>>>>>>>>> to add some information to the access log,
>>>>>>>>>>>> possibly look at some raw network logs and/or
>>>>>>>>>>>> look at HTTP headers on the client..
>>>>>>>>>>>> 
>>>>>>>>>>>> Somewhere in all of the above you should find out
>>>>>>>>>>>> where the session ID is getting dropped. Then you
>>>>>>>>>>>> need to figure out why. Only then you know why
>>>>>>>>>>>> this is happening can you start to think about a
>>>>>>>>>>>> solution.
>>>>>>>>>>>> 
>>>>>>>>>>>> Mark
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Mon, Apr 27, 2020 at 10:54 PM Martin
>>>>>>>>>>>>>> Grigorov <
>>>>>>>>>> mgrigorov@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Tue, Apr 28, 2020 at 2:23 AM AJ Chen
>>>>>>>>>>>>>>> <aj...@web2express.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> My web application using tomcat 6 can
>>>>>>>>>>>>>>>> track user session (cookie by default)
>>>>>>>>>>>>>>>> for mobile and PC users in dev
>>>>>>>>>>>>>>>> environment. But when
>>>>>>>>>> deployed
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> cloud server, it fails to track session
>>>>>>>>>>>>>>>> for some mobile users.
>>>>>>>>>>>> meaning,
>>>>>>>>>>>>>>>> servlet always creates a new session upon
>>>>>>>>>>>>>>>> user request.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Any idea why this happens?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Most probably there is a proxy in front of
>>>>>>>>>>>>>>> Tomcat in the cloud
>>>>>>>>>>>>>> environment
>>>>>>>>>>>>>>> which does not properly forward the
>>>>>>>>>>>>>>> JSESSIONID cookie.
>> 
>>> server.xml is configured for HTTPS.
>> 
>> Can you verify that you aren't being MITM'd? The TLS certificate you
>> host on your server is the one the client is seeing on the mobile handse
>> t?
>> 
>> Are you able to reproduce this error with the Tomcat "examples" web
>> application which includes a simple session demo?
>> 
>> I'm wondering if your application adds something extra to the mix.
>> 
>> - -chris
>> -----BEGIN PGP SIGNATURE-----
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>> 
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6p+iEACgkQHPApP6U8
>> pFiy6g/+NOKR0F+2rvYIhyDfOFe+BmmyCkqAK968DfuQ5DrnOdSPlDK9ARBjFcSt
>> +YsnQx9w4E0uGuj/uuBJSZAXyQH5gqTzrEv5o3zRuhvlLGhRBr46aUAknQoGq8JN
>> B8C8a9cYdspS4ggCgBGv6ardwJmzWXTHKj3SE6d1MoXPPSxXZpnr5dGI7nVlWib8
>> X1UgruIHM7OlU1teJ03t0AuzBzMgKYEgAgAQ1hc9tdgU+rrmHQCvZjm5MSGqMcay
>> Z0HKrXz+W1rH8V+r3HwajDejOagPuL40F01BxNIzX4GRgWjTQuIjwTI6z5qLi7SL
>> ZlCJZDwpKxdeeyV95X8nunKgHovalX6ECVJjJO7kIZVMw8s4eVfTJSzowraujaVd
>> mmxPgtkh6tDThY86axvIUbRGDP4RfHMuLUG7N3AIGpK/ra9zoOl+Vx61C0HZgZOK
>> OMHgcDAOxIQKygehSE13O/14juvo4zgAmpjmmu2PWzTSAHrvwLmLFOuYsRL/Czgk
>> MbnG0ALnXvhj7S2aFQF4/swmgI+Moau1grd6KgSrvGM2simxz0XE7DNJLeKh+Y/Z
>> WzJll8STVZ+mvGgWSc5iiq1rrkTY13AeUr/pxQsE2NBWnp2e/wK3KpOfBoCb+2QC
>> mubJLXAxsNpGHcRebxOvRXiba0nv7Gp5HZVe4suZJEj224X0vhk=
>> =OZbO
>> -----END PGP SIGNATURE-----
>> 
>> ---------------------------------------------------------------------
>> 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: Losing session between calls from mobile phone

Posted by AJ Chen <aj...@web2express.org>.
Chris and Peter,
Yes,  after using HTTPS in every url, session does not get loss any more.
Thank you for spotting the cause.

-aj


On Sat, May 2, 2020 at 7:01 AM logo <lo...@kreuser.name> wrote:

> AJ
>
> > Am 30.04.2020 um 22:22 schrieb AJ Chen <aj...@web2express.org>:
> >
> > The session problem happens when testing without SSL.
> >
> Just a thought:
>
> If the session cookie has the secure flag it will not be sent on http
> requests. (That would fail your test above in any case!)
>
> Now if that happens during regular https usage, it could be that one
> requests redirects to http. That will remove the cookie and a new session
> will be generated. The next https-request will have new cookie and then you
> start from scratch.
>
>
> Could that be possible?
>
> Peter
>
>
> > I'll try to test with Tomcat session manager example app. Thanks, Chris.
> >
> > -aj
> >
> > On Wed, Apr 29, 2020 at 3:05 PM Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA256
> >>
> >> AJ,
> >>
> >> On 4/29/20 13:46, AJ Chen wrote:
> >>> On Wed, Apr 29, 2020 at 10:28 AM Christopher Schultz <
> >>> chris@christopherschultz.net> wrote:
> >>>
> >>> AJ,
> >>>
> >>> On 4/29/20 13:24, AJ Chen wrote:
> >>>>>> Chris, When i use my latest iphone 11 to access the web app,
> >>>>>> tomcat server generates new session every time. It's normal
> >>>>>> use, not private browsing.> I did not change any setting on
> >>>>>> tomcat regarding session, use default session tracking. Is
> >>>>>> there any setting that can enforce using previous session
> >>>>>> (i.e. track session)?  Can I save the previous SessionID and
> >>>>>> use it to get the session with this id explicitly?
> >>> AFAIK, Safari Mobile doesn't do anything weird.
> >>>
> >>> Are you always using TLS (HTTPS)?
> >>>
> >>> -chris
> >>>
> >>>>>> On Wed, Apr 29, 2020 at 10:13 AM Christopher Schultz <
> >>>>>> chris@christopherschultz.net> wrote:
> >>>>>>
> >>>>>> AJ,
> >>>>>>
> >>>>>> On 4/28/20 16:13, AJ Chen wrote:
> >>>>>>>>> Andre, thanks for asking the questions. Yes, we try to
> >>>>>>>>> get understand the behaviors.
> >>>>>>>>>
> >>>>>>>>> We have seen iphone and other android phones, on
> >>>>>>>>> different carriers, from different networks, encounter
> >>>>>>>>> this problem - losing session. It does not seem there
> >>>>>>>>> is a pattern so far. Users use all kinds of phones.
> >>>>>>>>> Some of their phones experience this problem.
> >>>>>>
> >>>>>> Are any of them using "private browsing" or anything like
> >>>>>> that?
> >>>>>>
> >>>>>> Are you just using the standard Tomcat-generated JSESSIONID
> >>>>>> cookies?
> >>>>>>
> >>>>>> -chris
> >>>>>>
> >>>>>>>>> On Tue, Apr 28, 2020 at 12:08 PM André Warnier
> >>>>>>>>> (tomcat/perl) <aw...@ice-sa.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 28.04.2020 18:28, AJ Chen wrote:
> >>>>>>>>>>> Thanks. Martin and Mark.
> >>>>>>>>>>>
> >>>>>>>>>>> I can recreate the problem: I compare two
> >>>>>>>>>>> different mobile phones. One phone can log in and
> >>>>>>>>>>> proceed. Server log shows the same session persists
> >>>>>>>>>>> (same sessionID upon different requests). The other
> >>>>>>>>>>> phone can log in, but upon next request, server log
> >>>>>>>>>>> show a new session is always created (new
> >>>>>>>>>>> sessionId).
> >>>>>>>>>>>
> >>>>>>>>>>> Since session tracking works on PC browser and
> >>>>>>>>>>> some mobile phone, the
> >>>>>>>>>> proxy
> >>>>>>>>>>> (if any) in front of aws EC2 server should not be
> >>>>>>>>>>> the problem.
> >>>>>>>>>> Anything
> >>>>>>>>>>> else may be missing?
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Asking just in case : - are the 2 phones on the same
> >>>>>>>>>> network carrier ? - are they the same brand, or at
> >>>>>>>>>> least OS ? - if you connect them both to the same
> >>>>>>>>>> local WiFi, do they still act differently ?
> >>>>>>>>>>
> >>>>>>>>>> Note : no idea if this makes any difference, but
> >>>>>>>>>> we're trying to find a reason why they act
> >>>>>>>>>> differently when using the same Internet application
> >>>>>>>>>> server, right ?
> >>>>>>>>>>
> >>>>>>>>>>> -aj
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Apr 28, 2020 at 12:30 AM Mark Thomas
> >>>>>>>>>>> <ma...@apache.org> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 28/04/2020 07:47, Martin Grigorov wrote:
> >>>>>>>>>>>>> On Tue, Apr 28, 2020 at 9:11 AM AJ Chen
> >>>>>>>>>>>>> <aj...@web2express.org>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Anyway to fix it? thanks. -aj
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> First you need to investigate whether there is
> >>>>>>>>>>>>> a proxy. Then what kind of proxy. Then where is
> >>>>>>>>>>>>> its configuration. Then consult with its manual
> >>>>>>>>>>>>> and see whether there is something
> >>>>>>>>>>>>> wrong/missng.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'd recommend taking a step back.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Guessing at what might be wrong and then trying
> >>>>>>>>>>>> to fix the problem you have only guessed at is
> >>>>>>>>>>>> unlikely to work.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Can you recreate the problem? You can't tell if
> >>>>>>>>>>>> something is fixed if you can't recreate it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Once you recreate the problem then you can start
> >>>>>>>>>>>> to narrow it down. You need to track what is
> >>>>>>>>>>>> happening to the session ID. You'll probably need
> >>>>>>>>>>>> to add some information to the access log,
> >>>>>>>>>>>> possibly look at some raw network logs and/or
> >>>>>>>>>>>> look at HTTP headers on the client..
> >>>>>>>>>>>>
> >>>>>>>>>>>> Somewhere in all of the above you should find out
> >>>>>>>>>>>> where the session ID is getting dropped. Then you
> >>>>>>>>>>>> need to figure out why. Only then you know why
> >>>>>>>>>>>> this is happening can you start to think about a
> >>>>>>>>>>>> solution.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Mark
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Mon, Apr 27, 2020 at 10:54 PM Martin
> >>>>>>>>>>>>>> Grigorov <
> >>>>>>>>>> mgrigorov@apache.org>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Tue, Apr 28, 2020 at 2:23 AM AJ Chen
> >>>>>>>>>>>>>>> <aj...@web2express.org>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> My web application using tomcat 6 can
> >>>>>>>>>>>>>>>> track user session (cookie by default)
> >>>>>>>>>>>>>>>> for mobile and PC users in dev
> >>>>>>>>>>>>>>>> environment. But when
> >>>>>>>>>> deployed
> >>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>> cloud server, it fails to track session
> >>>>>>>>>>>>>>>> for some mobile users.
> >>>>>>>>>>>> meaning,
> >>>>>>>>>>>>>>>> servlet always creates a new session upon
> >>>>>>>>>>>>>>>> user request.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Any idea why this happens?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Most probably there is a proxy in front of
> >>>>>>>>>>>>>>> Tomcat in the cloud
> >>>>>>>>>>>>>> environment
> >>>>>>>>>>>>>>> which does not properly forward the
> >>>>>>>>>>>>>>> JSESSIONID cookie.
> >>
> >>> server.xml is configured for HTTPS.
> >>
> >> Can you verify that you aren't being MITM'd? The TLS certificate you
> >> host on your server is the one the client is seeing on the mobile handse
> >> t?
> >>
> >> Are you able to reproduce this error with the Tomcat "examples" web
> >> application which includes a simple session demo?
> >>
> >> I'm wondering if your application adds something extra to the mix.
> >>
> >> - -chris
> >> -----BEGIN PGP SIGNATURE-----
> >> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> >>
> >> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6p+iEACgkQHPApP6U8
> >> pFiy6g/+NOKR0F+2rvYIhyDfOFe+BmmyCkqAK968DfuQ5DrnOdSPlDK9ARBjFcSt
> >> +YsnQx9w4E0uGuj/uuBJSZAXyQH5gqTzrEv5o3zRuhvlLGhRBr46aUAknQoGq8JN
> >> B8C8a9cYdspS4ggCgBGv6ardwJmzWXTHKj3SE6d1MoXPPSxXZpnr5dGI7nVlWib8
> >> X1UgruIHM7OlU1teJ03t0AuzBzMgKYEgAgAQ1hc9tdgU+rrmHQCvZjm5MSGqMcay
> >> Z0HKrXz+W1rH8V+r3HwajDejOagPuL40F01BxNIzX4GRgWjTQuIjwTI6z5qLi7SL
> >> ZlCJZDwpKxdeeyV95X8nunKgHovalX6ECVJjJO7kIZVMw8s4eVfTJSzowraujaVd
> >> mmxPgtkh6tDThY86axvIUbRGDP4RfHMuLUG7N3AIGpK/ra9zoOl+Vx61C0HZgZOK
> >> OMHgcDAOxIQKygehSE13O/14juvo4zgAmpjmmu2PWzTSAHrvwLmLFOuYsRL/Czgk
> >> MbnG0ALnXvhj7S2aFQF4/swmgI+Moau1grd6KgSrvGM2simxz0XE7DNJLeKh+Y/Z
> >> WzJll8STVZ+mvGgWSc5iiq1rrkTY13AeUr/pxQsE2NBWnp2e/wK3KpOfBoCb+2QC
> >> mubJLXAxsNpGHcRebxOvRXiba0nv7Gp5HZVe4suZJEj224X0vhk=
> >> =OZbO
> >> -----END PGP SIGNATURE-----
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>