> 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
