• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Killing cookies when session is invalidated

 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.)
 
Ranch Hand
Posts: 153
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bear Giles
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic