User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0 Build ID: 20151103171328 Steps to reproduce: 1) Have Home page set to a page that requires basic authentication. 2) Open Firefox, page doesn't render until basic auth is complete (Desired). 3) Kill Firefox with kill -9. 4) Launch Firefox again, page renders without completing basic auth. (Not Desired) We noticed this when we flat out rebooted a computer, and were able to get into a restricted web page without credentials. Actual results: After a crash Firefox will render a protected page without re-authenticating. Firefox doesn't prompt for restoration if you crash on home page. Expected results: I would expect after a crash the Firefox to detect that the basic authentication, was for a previous instance of Firefox and erase credentials. Unless user is prompted to restore the page after the crash. Firefox doesn't seem to prompt for restoration if crash is on your home page.
Tim, Dietrich, anyone of you still working on session restore, or can you bring this bug to the attention of the right people?
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #1) > Tim, Dietrich, anyone of you still working on session restore, or can you > bring this bug to the attention of the right people? AFAIK there are no folks actively working on session restore right now, other than making it work with e10s. We're simply obeying caching rules here (I think). If the page would tell browsers to not cache anything then session restore shouldn't show anything (I think). SR restores pages from the disk cache, if stored.
IIRC there's no specific code around auth restoration, so Tim is likely right that it's likely something in the network/cache layer that's doing this. We do restore session cookies, which could be causing this if the page in question uses cookie+token after the initial auth step.
We very intentionally save the current logged-in state as part of session restore: beltzner and johnath insisted that the point was to get users back to where they were after a crash as fast as possible. I've long argued that we should not save this info after a CLEAN shutdown (bugs languishing because that's controversial too), but after a crash this is going to be a WONTFIX. In any case for most users it's the cookies that are more important -- not many sites use HTTP Auth. It would be nice if there were a user-discoverable way to turn off (or turn down) sessionstore--on about:preferences#privacy for example--so that concerned users could control it. For most users, however, the default behavior is the useful one.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I tried to reproduce: 1. Visit https://httpbin.org/basic-auth/user/pw (or http://httpbin.org/basic-auth/user/pw) and provide "user" / "pw" as credentials. 2. Kill the Firefox process. 3. Start Firefox again. 4. The visited page renders, as if authentication was provided. 5. However: Reloading shows up the authentication dialog again. I would say this behavior is reasonable, as the session restore doesn't actually reload the site from the server. If we were to not show anything or reload the site from the server, the user might lose information (such as form input), which is what session restore tries to prevent. In general, if session restore is of concern, the user can disable it by setting Preferences > Privacy > History > Firefox will: *Never remember history". I opt for resolving this bug as "invalid".
You need to log in before you can comment on or make changes to this bug.