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
