Because as I mentioned the servlet session is used to hold information as part of the login flow (i.e. from when you GET the /login to when you POST to /login)
On Fri, May 23, 2014 at 9:58 AM, Zac Harvey <[email protected]> wrote: > Thanks Scott, but now I’m even more confused! If the servlet session is > separate from the CAS single sign in session, then how is it causing my > login issue (where the form seems to clear/reset but not login)? > > > > *From:* Scott Battaglia [mailto:[email protected]] > *Sent:* Friday, May 23, 2014 9:53 AM > *To:* [email protected] > *Subject:* Re: [cas-user] Login page refuses to authenticate if > JSESSIONID has been removed > > > > No. The web.xml's session timeout only controls the Servlet session. CAS > uses the servlet session to maintain some information during the login > flow, but the CAS single sign session is separate and stored outside of the > web.xml session. > > > > On Fri, May 23, 2014 at 9:03 AM, Zac Harvey <[email protected]> > wrote: > > Thanks again Scott & Misagh! Just curious – how does this server-side > session timeout correlate with client-side logins? Say I set > session-timeout to 10 minutes; does that mean the user will be > automagically logged out after 10 minutes? > > > > *From:* Misagh Moayyed [mailto:[email protected]] > > *Sent:* Friday, May 23, 2014 8:53 AM > > > *To:* [email protected] > *Subject:* RE: [cas-user] Login page refuses to authenticate if > JSESSIONID has been removed > > > > web.xml, session-timeout. > > > > *From:* Zac Harvey [mailto:[email protected]<[email protected]>] > > *Sent:* Friday, May 23, 2014 5:47 AM > *To:* [email protected] > *Subject:* RE: [cas-user] Login page refuses to authenticate if > JSESSIONID has been removed > > > > Thanks Misagh! This seems to be my exact problem (and just like I > expected, a session expiry). > > > > My big question: it says that the remedy is to configure the default CAS > session timeout to be an appropriate value. How/where do I configure this > timeout (what file, what property, etc.)? Thanks again! > > > > *From:* Misagh Moayyed [mailto:[email protected] <[email protected]>] > *Sent:* Friday, May 23, 2014 6:22 AM > *To:* [email protected] > *Subject:* RE: [cas-user] Login page refuses to authenticate if > JSESSIONID has been removed > > > > Does this help? > > > http://jasig.github.io/cas/4.0.0/installation/Troubleshooting-Guide.html#login-form-clearing-credentials-on-submission > > > > *From:* Zac Harvey [mailto:[email protected]<[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=3AF7CCAE3C526ADB8BF8E00EDD20876Band > 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 > > > > -- > > 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 > > -- > > 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 > > -- > 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
