if you go to: http://gemal4.sprawl.dk/ the page outputs: Cache-control: no-cache Pragma: no-cache but if you enter some text in the login and password and tries to login you get an error. But when you press Back the password and login is still there. Expected: In other browsers when you press back to a page that has nocache the page is reloaded.

the summary is incorrect, not sure what it's supposed to read though, i'll leave it up to you.

Maybe the summary is better now, but marking invalid. And it isn't cache related, it's form related. When pressing back, Mozilla fills the form with the previously entered value, which is a very Good Thing! If you fill out a form, submit it, but made a mistake and go back, you wouldn't want to fill in everything again. If you want to get rid of these values, either add a "reset" button to that web page and press it, or reload the page. If pressing the reload button doesn't work, click in the location bar and press the Enter key.

This is really bad bad... What about when people leave the machine, and you can just go to the machine, press back a couple of times and log into a application because the username/password is there. That's why login pages always should use nocache.

You should never ever leave your machine unlocked. :) Okay, reassigning to Form Submission then, and changing summary again. I really don't think this is a cache issue. The password is not part of the web page (the HTML file), and that's all that is cached. And what about the password manager? It also remembers passwords, and here it is much more important not to leave without locking the desktop. (Unless you use encryption for storing the passwords and let the local password expire every few minutes.)

in my opinion this is a network cache problem. Since the login page is nocache, pressing back to the login page on other pages should instruct mozilla to reget the login page since it's not in the cache, because of the nocache.

eric, I'll let you take a look at this.

Setting milestone to mozilla0.9.1

Radha, it sounds like maybe here session history should get notified when Netlib recieves No-Cache headers so that it doesn't saves form control state for that page? Does that sounds right?

Eric, That does sound right. we can probably use the loadtypes for that purpose. nsDSURIContentListener::DoContent() can look in to the nsiRequest or the channel to figure that it was a no-cache request and set a loadtype(BYPASS_CACHE or something) that will add the page to history but not save the form values. we need to check for that flag in nsDOcSHell::PersistLayoutHistoryState() Another way is to save the values in History, but not restore it. LoaadType can be set to one of the existing types. See nsDocShell:Embed() and avoid restoring it. cc'ing gordon. Today in a meeting with him, there was a mention of caching data though the page says "No-Cache". Darin, Gordo, Can you clarify what happens in this situation.

Currently, if the server response says "no-cache" then we don't put it in the cache. In the future, this may change for POST transactions. Also, I don't believe that nsIHTTPChannel::BYPASS_CACHE is honored. It is just cruft that should be removed from nsIHTTPChannel. If this is the behavior that you want then you can use nsIChannel::FORCE_RELOAD in the load attributes.

These changes are a bit out of my area of expertise. Handing to the SH guru. :)

Cc mstoltz. See also bug 60877 (r. invalid), "sign-out from hotmail and then clicking on back button lands up inside the user's mail account". I don't like the idea of storing POST forms, but not normal pages, when the no- cache header is present. That's the opposite of what we do now for pages without no-cache, and it just seems weird.

our current plan is to store POST responses in the cache in such a way that they are only retreivable via session history. no-cache pages will be stored in the cache as well, but with an expiration time = now. session history tells HTTP not to validate content, which means that going back to a page with no-cache content, will result in content being fetched from the cache.

That seems right to me.

This bug is contrary to arguments made in bug 56346. I guess this should be marked "won't fix"?

I tried to go to the page above and get a forbidden message. Any otehr good test case with no-cache controls?

I see that nav 4.7 and IE don't restore the form values when going back to the above page. But, based on Darin's comments above on the cache policy and SH usage of it, I'm marking this bug Won't fix. It is a cache-policy issue rather than a problem with back/forward buttons or a bug in SH.

I'm not sure if I understand this correct. But: This is really really bad for use of Mozilla on public PC's. We have: Cache-control: no-cache Pragma: no-cache on the login page of our webmail application so that people cant just press "Back" and login as other people. What's the solution for us? Disable use of Mozilla?

We discussed this last week in a meeting. This is primarily a end-user feature issue than a bug in cache or form value restoration. In public PC situations, different profile can be used by each user, thus when a user exits, all the data for that profile is deleted which includes SH and form values. Another argument to the same problem is, what if the user submitted a wrong url and passwrod and wanted to go back and correct it. An option of using Pref is also being considered. Marketing is trying to help arrive at a solution for this.

I don't understand how preferences should help. I think of using webmail in i-cafes or on fairs or conferences. So people reading mail somewhere always have to switch browser settings? I think this is not useable because normal PC _users_ don't think about this security problem.

if you are concerned about privacy in such cases, just close the browser window. that will close the most obvious security "holes."

many (most) public machine doesn't allow you to close the browser window. Still think this is really really bad for mozilla security...

I tend to agree with Henrik about this. The argument in bug 56346 doesn't mention passwords. It seems reasonable that history entries should be cached, but password fields should be an exception. THe contents of a password field should not be remembered in history. Let's do what NS4 and IE5 do and not remember password data. Let's not deliberately make Mozilla less secure than NS4.

FWIW, this patch makes us behave like IE and forget passwords. This is different than Nav 4.x's behavior. Nav 4.x does indeed remember passwords. Not that I think this is a good idea, just noticed... :) So... since the problem and fix are layout, I'd be willing to take this bug if you think this is a good solution, Radha. Nominating for 0.9.2 as it improves security...

Wouldn't it be possible to just remember password as long as the page you go back is not using "Cache-control: no-cache" or "Pragma: no-cache". That would solve my problems.

Remembering passwords is not related to cache controls. I don't think there is a way thro' nsICachingChannel or any other interface to check that. Eric, I'm OK if you want to take over this bug and fix it. But, I'm still not convinced that this is a issue in public machines. I don't think the current behavior makes N6 less secure either. Now that dynamic profile switching is available, SH and related form values are destroyed when the profile is changed. Sites that have good security measures will not allow you to go back into the site, once you log off. For example, go to netcenter, login, do your work, sign off and click back, you are redirected to the login page. From a embedding point of view (like in kiosk modes), we don't believe this is an issue.

WHat if the user forgets to sign off?

That is user's mistake. if you go somewhere else from your webmail without signing off and click back, you will go back into the webmail session. we can't add features to cover user's stupidity. Some bank sites have a timer based logoff. My bank's website will automatically sign me off, if I don't perform any action for 1.5 minutes.

Ok, really, really good sites use session-ids even for login-screens. But I've not seen a single site that does so yet. Radha, I tried (with latest nightly-build) reading my mails using the webmail-interface of netcenter, signed out, chose the login-page from session-history, clicked on sign in (without needing to retype my password) and was logged in again. I really can't afford to tell any user to use N6 or mozilla as long as this security risk exists! I really encourage Eric to take over this bug and to fix it, please! P.S.: I'm not talking about users who forget to sign off, I talk about people, seeing a browser, using webmail, signing off, feeling secure. No one really wants to think about what to do with browser A and/or browser B to make him forget session history!

Oops, well... Sorry for the short notice, but I am on vacation now through 8-July-2001. I won't be able to make sure this gets in anytime soon. Radha, I'll leave it to you to see if the patch does something reasonable (never save passwords in session history), and if so, please feel free to get r/sr and check it in.

This issue appears to be related to Gagan's "clarity" bug, namely bug 90288 . That bug is pdt+ -- if you think the two issues are related, let's try and land Pollmann's patch too. If they are dupes of one another, then so be it -- someone should conclude this and mark it so. But note that bug 90288 makes *strict* mention of only the pragma directive not being respected. This bug suggests a bit more, and from what I understand from Pollmann's patch, fixes stuff with passwords. The real problem is respecting HTTP-EQUIV directives that tell us not to cache pages, not uniquely passwords related stuff. Cc'ing Gagan.

I am not completely convinced that forgetting passwords in SH is a good thing. But then I'd leave that as a debate to be discussed separately. Just to clarify bug 90288 deals with not caching (even for SH purposes) a "pragma: no-cache" page. This means hitting back button on a page that has that will indeed be refetched. Would let eric say if we try and refill form elements on a refetched page. So my changes in bug 90288 may or may not affect this one directly.

PSM security comments. About gagan's previous comment: My opinion is that if we refetch the page (especially as a result of a pragma no cache) then we should not use any remembered form values. About Alexander Helm's comment: If indeed it is still the case that one can log on to web mail, read it, log out then be able to log back in in the way Alexander described, then that's terribly bad.

Gagan says "r=gagan@netscape.com" and Vidur says "sr=vidur@netscape.com". Checking in to the trunk and marking bug FIXED.

This is a bit late, but I'd like to point out that this is possibly too aggressive. Occasionally I'll do something like misspell my username in bugzilla, and go back to change it. We already have an attribute which can be added to forms to disable the password manager, and ie honors that as well. It makes much more sense to act on that, instead. If its in the password manager, session history not caching it won't make a difference. (The attribute is autocomplete=off, see bug 63961) I'll note for the record that the page in the url bar here has autocomplete=off on the appropriate form. Basing what we do on that attribute makes more sense to me, although very quick test with ie seems to indicate that it does what we now do, and never caches the password in session history.

This doesn't appear to be completely fixed in one edge case - see bug 92532.

verifying fixed on build 2001-08-06-04-trunk. Its not remembering the password any more on the page in the URL.

Bradley: if you think this is the wrong way to solving the problem please open a new bug. Otherwise you comments from 2001-07-19 17:38 will be forgotten.

Several new bugs have been opened - see bug 93972 and bug 93027 (which has been fixed on the trunk)