If the system must not allow saving then the issue becomes very complex.
#Firefox refresh page cache software#
Per Tools->Page InfoĬache-Control: no-cache, no-store, no-transformįinally, of course it is not a security breach as the software can always save what it can display. On non-post pages, it does cache even in https in my singular test yesterday. Then your webserver will reply "the user is logged out" etc. This will instruct the browser to repost. I really hate it when some web site I briefly visit destroys all the history of everything else I've done in that session.īest idea is to use form posts. Personally, I consider the later to be anti-social behavior. I tried Googling the topic, and essentially every article I turned up suggested either using response headers to prevent caching or using JavaScript to destroy the history. I do already use Refresh to timeout the page and destroy the cookie, but that doesn't keep somebody using back to get to an earlier page in the session, if the browser is willing to display the earlier page from its cache history buffer without sending the cookie to the server to be told it's now invalid. If, in fact, response headers are "not reliable or sufficient to ensure privacy", I would welcome suggestions from other people in this group about methods that are more reliable. It does still keep the "no-store" data in the memory cache, but at least it sends another GET to the server when someone hits back, instead of just displaying what it has cached. I just discovered earlier tonight that FF3 does properly (by my interpretation) honor Cache-Control if I use GET for my forms instead of POST, so my immediate problem is solved. They did keep me from getting anywhere after logout with the back button in FF3, but I was still able to see financial information after I logged off by using about:cache. All 3 of them let me see sensitive information after I had logged off by merely hitting the back button in FF3. I tried National City, American Express and Capital One. You must bank at different places than I do. Perhaps this "bug" can be addressed by merely changing the incorrect label displayed by about:cache.
So if you want to declare that the area which about:cache labels a "Memory cache device" is really a "history mechanism" and not a "cache in volatile storage", then you win. Even the portion of RFC 2616 that you quoted clearly says that a cache "MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it." Unfortunately for my side, paragraph 13.13 of the same RFC says "History mechanisms and caches are different" and goes on to make it perfectly clear that history mechanisms can store whatever they want despite any restrictions on what can be cached.
RobertJ wrote:It seems based on what is in RFC 2616 that, page information can be stored in volatile storage (i.e., memory) and history buffers. I realize that in the poster's scenario, users cannot be trusted to do this, so perhaps the institution needs an idle-shut-down extension that will forcibly close Firefox for them? Wouldn't that be annoying. Would that make sense?Īs a practical matter, if User A does not want User B to access any part of their Firefox session, they should close the browser in a manner that will not allow session resumption. It goes on to say that using the response headers is not reliable or sufficient to ensure privacy which, is in essence what my friend at the cellular company said.īut servers have no way to reach in and flush the cache themselves, so if the headers are not honored, what's next? You could use client-side script to (1) go forward if there is forward history (this probably can be defeated) and/or (2) destroy the contents and reload the page if a certain timeout has passed.
0 kommentar(er)
