Thanks for the response. To answer your question: no, I haven't tried
IE6. I don't have a machine that has IE6 installed.
I could install a packet sniffer but I'm not sure there is any point.
The very first filter in my servlet is logging info about all cookies in
the header. I have no reason to think that the filter is "manufacturing"
cookies so I don't see a lot of value in sniffing the incoming packets.
It currently looks as though I was being fooled by leftover cookies. I
confess my head is kind of spinning from all of the testing I've done
and I may not have my story completely straight, but here are some
things I've found:
* The calculation of path variable in remove cookie has a bug, i.e.
when deployed in root context the value has the empty string
rather than "/" that is used when creating the cookie. I'll open a
JIRA and submit a patch.
* Looking back in my logs I see that I sometimes had multiple
"rememberMe" cookies in a single request. Perhaps they were for
different paths. It looks like signing out was clearing one cookie
but not the others.
* IE7's remove cookie operation is not reliable. I invoked this
operation from the Tools menu but still saw rememberMe cookies in
the request headers. "Delete all browsing history" seems to work
better.
* I don't understand where cookies are stored in IE. Some cookies
show up in the Cookies folder under Documents and Settings, but
not all of them (at least not as individual files). It is quite a
pain that you can't view individual cookies.
Anyway, I deleted my IE browsing history, fixed the path bug, and now I
can logout of IE7. At least for now.
Brad
Les Hazlewood wrote:
Hi Brad,
First of all, thanks for taking the time to debug this - I know
setting up a custom filter and trying multiple web containers is _not_
fun and certainly time consuming.
I have 2 recommendations:
The only reason I can possibly think of is that
CookieAttribute.removeValue is getting called sometime _after_ the
first bit of text has been rendered to the response, which means the
cookie header wasn't sent back successfully to the client. Have you
tried with IE6?
The final recommendation is use a packet sniffer and capture the raw
HTTP request being sent by IE7. If you could capture that, we might
be able to put it inside a test case and try it out...
On Mon, Feb 23, 2009 at 6:14 PM, Brad Whitaker <[email protected]
<mailto:[email protected]>> wrote:
I grabbed the commits from last night (thanks Les) and built the
jars today and have installed them in my Grails app. Everything is
working fine with Firefox 3 and Chrome but I'm still having
trouble logging out in both IE7 and Safari.
Based on the comments in CookieAttribute.java there were some
browser specific issues fixed in JSEC-94. I can't find any
discussion or info about this pre-apache issue. Does anyone
remember this and have any useful information about browser
specific issues?
My problem only occurs when I deploy on tomcat as ROOT.
(Unfortunately it does not occur when I run my app on Jetty in
Grails devel mode. The build and deploy to tomcat time really
slows down my investigation.) I added detailed debug logging to
CookieAttribute.onStoreValue() and CookieAttribute.removeValue()
and these methods seem to be behaving as expected. I added a
filter that logs the cookies contained in every incoming request
and I can see that both IE7 and Safari include the rememberMe
cookie in the request that immediately follows
CookieAttribute.removeValue(). I can't understand what the problem
might be unless it is some strange issue with 'path'.
(BTW, I initially thought that I had found and fixed a problem
with path: the path value being used in removeValue() may be
different than the path value used in onStoreValue() because the
fix for JSEC-34 is not being applied to path upon cookie removal,
only upon cookie creation.)
