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:
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!
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.
Joined: Jun 03, 2004
Invalidating the session should take care of removing the cookie and that's exactly what I try doing - to no avail.
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.