This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes JSF and the fly likes Clearing a cookie in the client using JSF (Mojarra) and Icefaces Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Clearing a cookie in the client using JSF (Mojarra) and Icefaces" Watch "Clearing a cookie in the client using JSF (Mojarra) and Icefaces" New topic
Author

Clearing a cookie in the client using JSF (Mojarra) and Icefaces

David Brossard
Ranch Hand

Joined: Jun 03, 2004
Posts: 109
Hi all,

I have a simple Icefaces app where I use cookies. One of the cookies is an authentication token. I have a commandlink which I use to invalidate the session. Unfortunately (and I suppose quite expectedly), session invalidation doesn't remove any client cookies.



I have found 2 ways to clear cookies. The first one is as follows:



The second is - I believe - merely a facade / shortcut to the former one:



References:
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#addResponseCookie%28java.lang.String,%20java.lang.String,%20java.util.Map%29
http://download.oracle.com/javaee/6/api/javax/servlet/http/Cookie.html

I think that my issue might be in my filters. I have 2 custom filters I wrote, one which deals with AuthN (and which gets the cookie), and one which deals with AuthZ. The cookie was set by an HTTP call from my webapp to a 3rd party authentication server which then redirects to my webapp. The cookie has therefore not been set by my webapp per se. Would that matter?

Does the code seem right to you? How can I possibly debug what I am doing incorrectly?

Thanks, and I hope this code helps others.


No matter what they say in Ohio, we're still first in flight!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16158
    
  21

This is one of the reasons I discourage indulging in Do-It-Yourself security systems. They're expensive. Here you are hung up on a security problem, rather than devoting time and energy to the application itself. And the tragic thing about it is that I suspect that I already know how to hack my way into your "secure" system, and I'm not even a very good (or evil) security hacker. And I presume you have a "captive audience", because there are people who refuse to enable cookies at all. Which would make them very poor customers for this app.

JSF has no direct interest in cookies. Probably because JSF and J2EE in general are expecting data to be carried in the session. Although that doesn't mean that there aren't still some cases where a cookie can help!

Nevertheless, the only cookie that the J2EE/JSF framework themselves should be interested in is the jsessionId cookie. The rest of them are up to you. If you delete a cookie in one place, but the cookie gets re-created downstream of there, it's up to you to ensure that doesn't happen.


Customer surveys are for companies who didn't pay proper attention to begin with.
David Brossard
Ranch Hand

Joined: Jun 03, 2004
Posts: 109
I couldn't agree more with your first statement. What I am doing now is a dummy demo where I have to use cookies. The problem you describe is exactly what I'm getting: cookie replay (if there is such a term) whereby I invalidate my session (i.e. I logout) but I can still go to sensitive parts of the website because the cookie is still there (as long as it has not expired).

Invalidating the session should take care of removing the cookie and that's exactly what I try doing - to no avail.

Again I entirely agree with your comment.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16158
    
  21

Cookies live in the browser (normally as a result of a request to the server), sent to the server (which may modify them), then passed back to the browser. Very rough sketch, since the server response is usually what prompts the browser to construct, modify, or destroy a cookie. In a sense, they're the mirror image of HttpSessions, which live in the server., although sessions are NEVER passed to the browser - just the session handle.

So destroying a session has zero effect on cookies. The only things that can destroy cookies are expiration, a response from the server or the user forcibly clearing cookies via a browser menu command or the like. Well, short of uninstalling the browser, reformatting the local hard drive, etc.

Thus the only way to get rid of these (in)security tokens is to have application code explicitly remove them. And if the browser should choke and die while processing the response, the cookie may very well remain in the user's cookie database when the browser restarts. Come to think of it, I do think that some browsers have a user option to clear cookies on shutdown in addition to the cookie-destroying methods listed above.

Sessions don't suffer the same failings. When a webapp issues a session invalidate command, the session is disconnected from its handle in the session/handle map, so even if the jsessionid cookie isn't destroyed, using the handle won't return the session anymore.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Clearing a cookie in the client using JSF (Mojarra) and Icefaces