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 <l...@kreuser.name> wrote: > AJ > > > Am 30.04.2020 um 22:22 schrieb AJ Chen <ajc...@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 < > > ch...@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 < > >>> ch...@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 < > >>>>>> ch...@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) <a...@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 > >>>>>>>>>>>>> <ajc...@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 < > >>>>>>>>>> mgrigo...@apache.org> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Tue, Apr 28, 2020 at 2:23 AM AJ Chen > >>>>>>>>>>>>>>> <ajc...@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-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
