Your second and third scenarios have nothing to do with the servlet session. Therefore the 20 minute questions are not valid.
As mentioned, the servlet session is only used to maintain some state during the login flow. It is NOT used for the single sign on session. On Fri, May 23, 2014 at 10:08 AM, Zac Harvey <[email protected]>wrote: > Sorry, last followup question here (I promise) – I don’t think I worded > my last question quite right. > > > > Say I set the session-timeout from 5 minutes (the default) to, say, 20 > minutes: > > > > 1. When does the “20 minute” timer start ticking (meaning, what even > triggers the session-timeout to begin counting)? A user logging in? > > 2. Scenario A: the user logs in and continuous to use several apps (all > joined via SSO) for the full 20 minutes. What happens when they do a page > refresh after the 20 minutes is up? > > 3. Scenario B: the user logs in and then ideles for the full 20 minutes. > What happens when they do a page refresh after the 20 minutes is up? > > > > Thanks again for all your help thus far – getting answers to these > followups should clear everything up for me! > > > > *From:* Scott Battaglia [mailto:[email protected]] > *Sent:* Friday, May 23, 2014 10:03 AM > > *To:* [email protected] > *Subject:* Re: [cas-user] Login page refuses to authenticate if > JSESSIONID has been removed > > > > It all depends on your user base. At a previous employer, most people > didn't leave the login page open unused for a while so we could use a > shorter time (i.e. 5m or 10m). If you've got a user population that does a > GET /login and then hangs around for hours and expects POST /login to work, > then you'll need a larger time :-) > > > > On Fri, May 23, 2014 at 9:59 AM, Zac Harvey <[email protected]> > wrote: > > And, as a 2nd question there, how can I test to make sure that setting > session-timeout to a larger value is in fact fixing my login issues? > > > > *From:* Zac Harvey > *Sent:* Friday, May 23, 2014 9:58 AM > > > *To:* '[email protected]' > *Subject:* RE: [cas-user] Login page refuses to authenticate if > JSESSIONID has been removed > > > > 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]<[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 > > -- > 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
