File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB and other Java EE Technologies and the fly likes Killing cookies when session is invalidated Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Killing cookies when session is invalidated" Watch "Killing cookies when session is invalidated" New topic

Killing cookies when session is invalidated

Bear Giles

Joined: Mar 16, 2006
Posts: 25
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.)

SCJP 5 & 1.4, SCWCD 1.4, SCBCD 1.3; Security+
Shailesh Kini
Ranch Hand

Joined: Oct 17, 2001
Posts: 153
Hello Bear,

Here's my thought.... Not sure if this is the right way to do it but...

Correct me if I am wrong. From what I understand about SiteMinder... it is the first to intercept any request, even before it reaches your filter. Only after successful authentication SiteMinder forwards the user request to your application. Your application at this point should only check if there is a session already created (use session ID from cookie passed by SiteMinder with the session id returned by your current session)... if not create one. I do not think your filter needs to validate the session again on your end and redirect the user to login screen.

Please make sure that the websphere session timeout is always a little > than your SiteMinder session timeout.

This is only true if you are using SiteMinder for Authentication.

Shailesh Kini.
Rejeev Divakaran

Joined: Aug 12, 2007
Posts: 27
As I understand your system:
1) if there is no cookie it assumes a first time user and redirect to registration page (for this you need to set a cookie with 0 expiry date)
2) if there a session cookie (with name JSESSIONID) and it is invalid, redirect to login page
3) if there is no session cookie redirect to login page
4) if there a valid session cookie allow to proceed

Where do you need to login twice?
You need to invalidate session during logout to invalidate the session cookie

Regards,<br />Rejeev<br />Blog: <a href="" target="_blank" rel="nofollow"></a>
Bear Giles

Joined: Mar 16, 2006
Posts: 25
Hmmm, you're right. Maybe we're approaching this the wrong way since we've been focused on how the system behaves on our development boxes (no siteminder). It's been hard to test since we don't have siteminder available to us here, only on the testing/staging box... and there only until the new site goes live.

On the other question, we didn't have problems when we had the implicit <%@ page session="true" %> on all pages. The access filter could reliably determine that a stale session id was due to a timeout and redirect the user to the login page with a friendly note. But then we had to remove the cookies from the public pages (per federal policy) and the problems came up.

We've tracked the source to application server failing to release cookies when a session is explicitly invalidated and the login sequence having a race condition. At first we couldn't log in at all, but a change to the filter (so it creates a new session when an old session id is seen, under the rationale that the user has already logged in once so shouldn't mind a new cookie) means we succeed on the second try.

The obvious answer, to allow cookies on the login page anyway, won't work since the site design has the login panel on the home page. After all, it's just a link that's captured by siteminder.
I agree. Here's the link:
subject: Killing cookies when session is invalidated
It's not a secret anymore!