Firefox 4.0b7 and 3.6.12 STR: 1. Log in to preview 2. Log out observed behavior: User is still logged-in and cannot log out even after multiple attempts reproducible: sometimes extra brownie points for fixing this, because it is driving me nuts. screencast: http://screencast.com/t/3B8dQIKq headers: https://addons.allizom.org/users/logout?to=/en-US/firefox/ GET /users/logout?to=/en-US/firefox/ HTTP/1.1 Host: addons.allizom.org User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:22.214.171.124) Gecko/20101026 Firefox/3.6.12 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en,kn;q=0.7,en-us;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Referer: https://addons.allizom.org/en-US/firefox/ Cookie: csrftoken=25671f410e34f4f2aeabb0f30989bd76; amo_home_promo_seen=5; AMOappName=firefox; sessionid=2964fd8dad65cd055d35176543987b49 HTTP/1.1 302 Found Server: Apache X-Backend-Server: pm-app-amo24 Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0, private Content-Type: text/html; charset=UTF-8 Date: Fri, 12 Nov 2010 19:33:51 GMT Location: https://addons.allizom.org/en-US/users/logout?to=%2Fen-US%2Ffirefox%2F Keep-Alive: timeout=5, max=1000 X-AMO-ServedBy: pm-app-amo24.mozilla.org Pragma: no-cache Via: Moz-Cache-pm-zlb-amo01 Connection: Keep-Alive X-Powered-By: PHP/5.2.9 X-Cache-Info: not cacheable; response specified "Cache-Control: no-store" Content-Length: 0
This is hitting /logout in PHP so the django sessionid cookie sticks around, but AMOv3 is cleared. It seems like we should be serving /logout from zamboni since we have code to clear the AMOv3 cookie after clearing sessionid. This will leave the remora session in the db but we have gc for that already. > extra brownie points for fixing this, because it is driving me nuts. If you hit /z/logout this should work better.
I thought we kept login/logout on remora for a reason. If zamboni has "remove amov3" code though, we could do that. Otherwise telling remora to delete "sessionid" would be easy too.
It looks like we already have remora deleting the django cookie. // delete the django cookie setcookie("sessionid", "", time()-3600, "/"); I bet this is busted because of the new SESSION_COOKIE_DOMAIN, and if that's true we need to fix it before the next release.
Hmm, that would be a good call and an easy fix. Krupa, can you show us all your *allizom.org cookies? If jeff is right, you probably have two named sessionid with slightly different domains
I delete both cookies in r77551. Perhaps this is fixed?
I never saw the problem, but this clears out r and z sessions for me.
Clouserw, Sorry I didn't see your request, as I wasn't paying much attention to my bugmail over the weekend. Also this is fixed. thanks.