We have a filter that checks for a valid session before allowing access to protected pages. If not, they get sent to a login page. TPTB wanted us to also provide an explanatory message ("your session has timed out") when the user has requested an invalid session. Good UI since it lets the user know why they're back at the login page.
Unfortunately it looks like we're getting the session cookie sent back to the user even after invalidating the session. Not sent with a '0' max age to kill it immediately, sent with a '-1' max age to tell it to stay around for awhile.
From the UI side, this means that after the first login the user always has to log in twice since the first in the filter sees an invalid session. (The filter will create a session when redirecting to the login page. If we don't do this explicitly the user can -never- log in!) They can't just enter trash either -- that always takes them to a 'registration' page.
I tried cheating and setting the max age to 0 in the
request header. That works with
tomcat (development), but not websphere (deployment). I know this is risky since JSESSIONID is a protected cookie that should only be managed by the app server.
Does anyone have ideas?
BTW we're also looking at adding yet more code to the filter, but it's a mess since we have to deal with SiteMinder, some mandatory overrides based on role inconsistency or mandatory messages, etc. Simply nuking the cookie would be a -lot- simpler.
BTW2 this is a government site and we have to take care to only create cookies when required -- the /public/ pages are supposed to be cookie-free. This problem only came up after TPTB noticed we were always creating cookies and made us remove them from those pages. The login page is obviously public. (Hmmm....)
(Hope this is the right bar -- it didn't seem to fit in the EJB/J2EE one.)