Does this help? http://jasig.github.io/cas/4.0.0/installation/Troubleshooting-Guide.html#l ogin-form-clearing-credentials-on-submission
From: Zac Harvey [mailto:[email protected]] Sent: Thursday, May 22, 2014 12:57 PM To: [email protected] Subject: [cas-user] Login page refuses to authenticate if JSESSIONID has been removed Last week I rolled out a new, custom login page to our test CAS server (where our QA team works). Before this we were using the default CAS login page (under src/main/webapp/WEB-INF/views/jsp/default, etc.). For the last week, I've been receiving complaints from many testers that sometimes, intermittently, they're unable to login. What happens is that they: 1. Attempt to login with their username/password (our underlying AuthenticationHandler didn't change at all, so their credentials should be working) 2. The form essentially resets but does not log them in (both the username and password fields clear) After spending an enormous amount of time troubleshooting this, I am able to reproduce it. 1. Login and then log out of CAS (this step might not be necessary but I believe it sets the rest of the steps up to become reproducible; under the hood I think its correctly setting and then clearing the CASTGC and JSESSIONID cookies) 2. Go back to the login page (in our case: https://devauth01.ourcompany.org:5443/login). 3. Check for the existence of a JSESSIONID cookie in your browser - it seems to always there; perhaps it is set by CAS when the login page is fetched by the browser. Remove it. 4. Attempt to login. 5. Just like my QA testers are reporting, the page redirects to https://devauth01.ourcompany.org:5443/login;jsessionid=3AF7CCAE3C526ADB8BF 8E00EDD20876B and does not bring you to the "Log In Successful" page. Instead the form just resets, but you're just staring at a fresh new login screen. So, a few questions on this: (a) I know that my QA testers are not going in and manually removing cookies (honestly, I don't think they would know how). But I'm wondering if something is happening where they are keeping browsers open for too long, or perhaps closing tabs but keeping the main browser open, and the JSESSIONID is expiring? Or perhaps some other process is somehow clearing it? Does any of this make sense? (b) What's the fix? Regardless of *how* the JSESSIONID is getting lost (either by manually removing the cookie, or by some weird expiry or other voo doo magic), it's quite apparent to me: if the JSESSIONID doesn't exist when the user attempts to login, then the form won't submit and the user won't be authenticated. So what's the solution here? Thanks! Zac Harvey Senior Technical Lead - Internal Engineering CommerceHub 255 Fuller Road Suite 327 Albany, NY 12203 518.810.0700 Ext: 3622 http://www.commercehub.com -- 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
