User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.9 (KHTML, like Gecko) Chrome/5.0.307.11 Safari/532.9 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:22.214.171.124) Gecko/20100115 SUSE/3.6.0-1.2 Firefox/3.6 GTB6 Session cookie remains active after browser shutdown and user is logged in forever. Exiting the browser does not delete the cookie even after system reboot. Reproducible: Always Steps to Reproduce: 1. Session cookie is set by a web application login with session_start() //php 2. In all other browsers when closing the browser the session cookie is deleted (as expected) 3. In Firefox it remains and when restarting the browser (even after >24h pass) you are still logged in (session is active!) Actual Results: User remains logged in forever Expected Results: Session cookie must be deleted on browser close
Just tested on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729) Same bug
Pretty sure this is invalid. I just set a session cookie using session_start, restarted Firefox and the cookie was gone. This is the case on Firefox 3 and 3.6. I can't think of any reason why the behavior would be different on 64-bit. George, you say "you are still logged in" in your step 3, but did you actually check the cookie manager to see if the cookie is still there when you restarted? CCing the cookie module owner to sanity check.
I just tested also version: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) Same result. Yes - the cookie is active and not deleted. I checked. If I delete it manually I am not logged in any more and session is over.
Here is what I did for simple test: 1. First I clean all cookies, cache and everything 2. I run the code: <?php session_start(); echo session_id(); ?> 3. I see the cookie is set with parameter: Expires - At End Of Session 4. Close browser 5. Run the browser again with empty page only 6. The cookie is still there with same ID and parameters (session is active)
Can you try this in a new profile please: http://support.mozilla.com/en-US/kb/Managing+profiles I'm using a very similar test on my end, and the cookie is deleted when the browser is closed. This would be a very serious regression and it is very unlikely that we could have released it in all these different products without someone noticing before now. I highly suspect you have a non-standard configuration which is producing this behavior. For example, what is the value of your privacy.clearOnShutdown.cookies pref?
Does Firefox restart with your tabs from last time (what is your home page preference say in the options/preferences dialog)? If so this is probably bug 443354 which we've argued over internally for quite a while.
Yes, this is most likely just sessionstore behavior. One of its jobs is to save session cookies, so if you leave a tab open with said site, you'll get your session cookies saved forever. A simple test is just to close the tab and then restart the browser. Do the cookies persist in that case?
Brandon, The values were: in the Linux version: privacy.clearOnShutdown.cookies = false in the Windows version: privacy.clearOnShutdown.cookies = true Nevertheless the problem was visible on both versions. Anyway I have reset them both. Daniel, My preferences were to open last tabs. After configuring Firefox to start with a blank page - the cookie was deleted (as expected). So yes - it seems it is the same bug you are citing. Sessions cookies are not deleted when preferences are set to restore previous tabs. Dan, If I close all tabs before quitting session cookie is deleted too after restart. So maybe it is correct to relate this bug to the one cited by Daniel. Anyway it is still a security issue imho.
> Anyway it is still a security issue imho. Mine too. Others insist this is a choice and that unless you've closed the tab this is what users want.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 443354
You need to log in before you can comment on or make changes to this bug.