-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bon,
Bon wrote: > I've monitored the value of cookies with debug mode at server > running, and the cookie values were be set to the new values. > > I'm not sure what effect of setting the session as invalidate and > setting new cookie values, I think set session as invalidate was > telling the server this session should be invalidated, and set > cookies as new values was telling the client browser to set the new > value to cookies, what I think as that, and I'm not sure do I right > or wrong?! Calling session.invalidate() invalidates the session. The servlet specification makes no demands about deleting any cookies on the client side, so my guess is that Tomcat does not go through the trouble of sending a dead cookie back to the client. If you want to kill the cookies on the client side, you are welcome to do so. I'm just suggesting that it is not necessary to remove those cookies unless you /really/ want to. In terms of invalidating the session and getting new values afterward, consider this scenario: 1. User logs into your application and is assigned a session, which sends a JSESSIONID cookie to their browser. 2. The user logs out of your application. The session is invalidated, and your code "deletes" the JSESSIONID cookie by sending a JSESSIONID cookie with maxage=0 and issues a redirect to the client. 3. The client deletes the cookie due to #2 and then redirects to the new URL. 4. The new URL requires a session and so a new JSESSIONID cookie is created and sent to the client. #4 can happen a number of ways, but in my experience the most common way is to send the user to a JSP that has not yet session="false" in the <@page> directive. In this case, the session is created whether you need it or not. > Why I attempt to delete the cookie from client's machine, that is a > requirement from my desinger, and I don't know why and I don't need > to know(I've asked why do that before....) Hah. Probably some "security" requirement. > the redirection is a complicated linking flow, and I'm sure it was > properly, because it was working well after I changed the logout URL > path. Why we do that from a main site redirecte to second site and > finally redirecte back to the main site, that is becausr we want the > both sites to clean-up their own cookies when logout was be > requested. This is reasonable. > now, I still don't know why I must change the logout URL path (the > URL path of cookies modifier) same as the login URL path (the URL > path of cookie creator) when I was through the main site to second > site, and they are at same host by different server port number. But > if I just open a new browser and to request the second site logout > URL(with different URL path), then the cookies of second site could > be expired by this request! I'm not sure I fully understand what you're saying, here. Just to clear a few things up, cookies contain: 1. A URL path that is used to identify which URLs should get the cookie 2. A name and value 3. Expiration information Let's say you have two JSESSIONID cookies for your two applications, hosted at the same site on the same port. Here's what they might look like (values removed because they are irrelevant): Cookie 1: url=http://www.mydomain.com/first; expiration=-1; name=JSESSIONID Cookie 2: url=http://www.mydomain.com/second; expiration=-1; name=JSESSIONID Note that the cookies are identical except for the url: one says "first" while the other says "second". If you are visiting /second, the cookie from /first will not be sent by the client. The opposite is also true for visiting /first: the cookie for /second will not be sent. If you need to remove the cookies from both sites, you'll need to either 1. Send two cookies on logout and hope that your client allows one site to expire another site's cookies (which probably won't work). or 2. Expire one cookie, then redirect to the other app and repeat the process (which is what you're doing in your application). I don't understand the "logout URL and login URL need to be the same" thing you're talking about above, though. Hope that helps, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkYY3MACgkQ9CaO5/Lv0PBh3wCgk2RDEO9STFF+Za4zOjWWgFgF lQ8An1KeTHVp0b3egLe7Aj9BirrBZQf4 =jVhA -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
