server.xml is configured for HTTPS. -aj
On Wed, Apr 29, 2020 at 10:28 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > 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. > >>>>>>>>>> > >>>>>>>>>> Martin > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> aj > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ---------------------------------------------------------------- > - --- > >> > >> > >>>>>>> > - --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For > >> additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6puSoACgkQHPApP6U8 > pFhrYhAApGIhxcL18qk0pFqkmbedAFn6YaLnIbrZJ5GOJwSZkpUiucOVpiIPpsR7 > qcYe7XTJp5vcZhZoCDtXSTejjcpwrHZDwbCTsMbFne8/NDDeiiHEsi5/zSYVSEq6 > zyNZi9okZ4WtbTg+1d2tIiXLWGfPqrhnguZx0xbfZ5aOi5MGH/Fszj6e9qEk+y2x > ObLt2DwX1pLv8hEWy4ekmVZcSY6D1SRnjWxihp1nWXZHfPGQYnjO1HhiB62INPeI > 75UGl0Dqr1ftqgk+rIUtS9mazDsffCqB5q1l1WokgT/hktTSZ35Y3LI/Ka2bSM4r > mC/KZeR6E/4vOqmLgZdeg6+1bcz8n79KsEEdCgv4h+5wiKM6XqUIT+mCKzXJrtvs > sqZKQmAc9ZiVqAUKEUE/fQZHcS+GQhKmSC4tSuiiBpCVUXH+FpP8ZbMPmiJ60Frc > 2Qvod3RdvskcEzZ5wcrfav6tcvx1zyZW1BYqEu3ayK9vaFt9b0dj3yWB2cw04dHP > ILF26ttmntBbu1R1r7L2b0fGGzp+NrkWaoqLZdxpATsEdT2E2SOP8Xch5/XzHIbA > UUisykaGRDtm7HCK+RuXPIV5QrjPDw+XcywyR7Q2Ejqd7GDb4AttMdsB7KswSU96 > 3zwa5IJT5yjl1GRzTKTvyi3AL8wHb/GJBC0j/4GflhmyTkzQbYM= > =olwv > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
