It looks like JSESSIONID is somehow involved - let me ask this: If a JSESSIONID cookie exists in the browser, but is somehow invalid or expired, could it cause this type of behavior that I'm seeing? I'm wondering if this is the root cause of my issues here, because JSESSIONID is the only cookie that exists when the user first goes to the login page (before logging in and submitting the form). So this is the only CAS-related cookie that, when deleted, could be fixing this weird issue for my users.
My theory: if the user goes to the login page and somehow has a bad JSESSIONID cookie, then somehow this affects the login HTTP POST and causes the user to be unable to login. Thoughts? -----Original Message----- From: Zac Harvey Sent: Wednesday, June 04, 2014 10:21 AM To: '[email protected]' Subject: RE: [cas-user] Need to clear browser cookies in order to login Marvin, Thanks for responding here. I now understand that 5 days is extreme and will strongly consider toning it down to a few hours. However, before I tuned it to 5 days, I had it set to 2 hours and these same problems were still occurring! I really think there's something to these cookie deletes. This problem goes away the second a user deletes their browser cookies. Can you (or anyone else) weigh in as to how deleting cookies would solve this problem? And perhaps even propose what the solution might be? Thanks again! -----Original Message----- From: Marvin Addison [mailto:[email protected]] Sent: Wednesday, June 04, 2014 10:16 AM To: [email protected] Subject: Re: [cas-user] Need to clear browser cookies in order to login > I’ve beefed up my servlet session timeout to 7200 (... 5 full days). That amount of beef may lead to coronary problems. > when they submit the login form, the form just resets and clears the > username/password field instead of authenticating them and > redirecting. Thoughts? The behavior you have cited is by design under an expired session condition: when a user posts credentials to an expired flow (backed by the session), a new flow is created and the user ends back up at the initial flow state which is an empty login form. In most cases simply entering credentials and posting them allows login to proceed. I understand you to say that an empty login form is repeatedly displayed on every attempt to post credentials; is that correct? In any case there's some evidence the servlet session is expired despite your extreme timeout. I should note that your session timeouts are well beyond anything we might encounter in a test environment. The default on Tomcat is 30 minutes; we have gone as high as 4 hours. 5 days is arguably ridiculous. What problem are you trying to solve with such extreme session timeouts? I'm hopeful treating the root problem instead of the symptoms may be more fruitful. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
