Thanks again Marvin. This is starting to make sense. I tuned session-timeout back to 5 minutes and redployed the server. However the problem is still happening, and as you said, I am beginning to suspect something wrong with the servlet container.
So in IE, I went to the login page, deleted all the cookies, logged in and checked my JSESSIONID. It was a long string starting 2C42BD... I then (still inside my app) deleted all the browser cookies and then hit F5 (refresh). I am still logged in, and the JSESSIONID is still the same exact string. What does this mean to you? If it is a container issue, where might I start digging in? Thanks again for all the help thus far! -----Original Message----- From: Marvin Addison [mailto:[email protected]] Sent: Wednesday, June 04, 2014 10:42 AM To: [email protected] Subject: Re: [cas-user] Need to clear browser cookies in order to login > 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? Yes. As I said the behavior is by design. An expired session corresponds to an invalid flow. As I noted, however, simply reposting credentials usually allows login to proceed. That's because the servlet container typically creates a new, valid session with a distinct JSESSIONID for the new flow. If you don't see JSESSIONID values changing when you're hitting your problem, that's a sign of servlet container misbehavior. > JSESSIONID is the only cookie that exists when the user first goes to > the login page That cookie conveys the session identifier; it MUST exist prior to authentication since it backs the Spring Webflow state. > So this is the only CAS-related cookie that, when deleted, could be fixing > this weird issue for my users. Makes sense. CAS is configured to create a session if one does not already exist. Deleting the JSESSIONID cookie is equivalent to the "does not have session" condition. > 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. Correct. Not much help though. It simply begs the question, why is the session invalid? I imagine you may be running into some boundary condition with such a large session timeout. I would hope backing off resolves it. Again, why do you need a session timeout longer than default? At one time the CAS session was configured for 5 minutes with the thinking a session is only needed for the brief time of showing the login form and processing the submitted credentials which under most circumstances happens in a matter of seconds. Why do you need more? 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
