We have a J2EE application (running on -cough- IE only) that uses JSESSIONID to manage session state between client and server. Some of our customers use a third-party web application (https://mdoffice.sentara.com/) in which the client Javascript onload method calls:
document.execCommand("ClearAuthenticationCache");
This smashes our JSESSIONID cookie in the browser and hence causes the the app server to see subsequent requests from our IE client window as an invalid or timed out session and the user gets kicked out. Our server is OAS/OC4J, but I doubt this it matters: The same basic behavior occurs if I hit the above URL while logged into my online banking.
In trying to research this, I found that most folks are interested in duplicating this behavior in non-IE browsers. I'm interested in how to protect against it. We verified that our session cookies are have domain scoping, but the above command doesn't seem to honor that. We have a lame work-around by which we launch IE with a -noframemerging argument. That's ugly, and also ends up messing with our logic that tries to limit the client to a single login.
I can't find much useful on MSDN, but this article (http://blogs.msdn.com/b/ieinternals/archive/2010/04/05/understanding-browser-session-lifetime.aspx) does make it clear that the above command "...clears session cookies ... for ALL sites running in the current session".
Does anyone know of either:
- Obviously preferable: A way to protect our precious session cookies from ClearAuthenticationCache?
- Vane hope: A less aggressive alternative to ClearAuthenticationCache that we might tell our customers to communicate to the 3rd party? (Of course, they'd have to do this with any 3rd party that causes this problem. Currently there's just the one.)
Thanks for any help!