So every call to /cas/logout is effectively abandoning sessions? Bill
On Wed, Mar 20, 2013 at 9:02 AM, Andrew Petro <ape...@unicon.net> wrote: > CAS developers, > > top.jsp in line 22 or so has a Page directive requiring a session. > > <%@ page session="true" %> > > ( http://goo.gl/ieAvg ) > > It looks like this was last touched in CAS-929 when Scott resolved that > issue. > > https://issues.jasig.org/browse/CAS-929 > > The comment on the commit suggests that the true is required for Tomcat 5.5, > but false is fine for Tomcat 6 (and later?) > > https://github.com/Jasig/cas/commit/24de8c19d2ed3a7aaf490f5db3d0b8f48f7b747a > > Anyone see any reason I can't flip this back to false for a client adopting > CAS under Tomcat 7? Troubleshooting a weird bug [1] and one effect of this > directive in top.jsp is to make the *logout* JSP create a new session, which > then (here's the weird part) gums up the next login attempt from that > browser session within the servlet session duration. Flipping this back to > false appears to resolve the bug, though of course I'll also want to follow > up on why CAS can't cope with a fresh new session. > > Supposing there's no problem with switching this back to false in > deployments in recent Tomcats, I'd like to offer a pull request that adds a > comment to top.jsp documenting that it's believed to only need to be true > for Tomcat 5.5 and earlier so that other adopters can more easily be aware > of and make this optimization. If there emerges consensus among CAS > developers, I'd like to go further and make the default false again, with > the comment suggesting that Tomcat 5.5 adopters make the change. > > At what point can we decide Tomcat 5.5 is no longer a servlet container > latest CAS needs to support? > > Andrew > > > [1]: Weird bug observed in client environment. : 1) log in to an > application via CAS. 2) Log out from application, terminating > application-local session and redirecting to cas/logout . This terminates > previous and issues new servlet session with corresponding JSESSIONID > cookie. 3) without closing browser, try to log in to the application again > via CAS. This deposits you to the CAS login form, of course. 4) correctly > complete and submit the CAS login form, but be rejected! CAS redirects back > to and displays login form again, issuing a new JSESSIONID. 5) correctly > complete and submit the CAS login form. Success! redirected to application > with service ticket. 6) move on with your day, possibly rolling your eyes > at that pesky central login screen (I haven't replicated this in vanilla > CAS yet, but that's not dispositive since there are configuration > differences between my test env and client's environment). > > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: wgt...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
