Yes, every request to /cas/logout results in a new, abandoned session. The impact of that is of course mitigated by tightening session duration, and in any case a mere new session shouldn't be trashing the next login attempt for this particular CAS adopter or anyone else. So I don't mean to overstate the magnitude of problem here. I'm just going for, hey, creating sessions CAS doesn't need isn't a great practice, appreciate the workaround for Tomcat 5.5 silliness, but Tomcat 5.5 is getting really old.
On Wed, Mar 20, 2013 at 9:49 AM, William G. Thompson, Jr. <wgt...@gmail.com>wrote: > 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: > ape...@unicon.net > 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
