Re: Forcing a page to be read from server and not from browser cache

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Malka.

I do not know the answer to your question, precisely, but I just wanted to make the following comment, because I have encountered the same kind of situation or question often before.

The general principle is : a user accesses your site, and you *give* him a html page. Now he has it, and it's "his", and he can do with it anything he wants. Ultimately, you have no control.
You have to accept that, that's the way it is.
You can send all the pragmas and cache-control instructions and cookies you want, but because they decide which browser they use and how they set it up and what bugs it has, they are the masters. For example, they can save your page to disk, and then re-open that file with their browser whenever they want, and click on the links in it. Fighting all the different ways to do this, is a lot of work, and you can never win 100%. What I am saying is, if you are thinking of this as a security mechanism, then forget it.

Once you accept that, fundamentally, then you can start thinking of ways to *help* the users not to use outdated pages etc.. and maybe someone else can tell you what better headers to use, to have a better chance at success.

If all else fails, and it is really a problem to you, you could try things like having your pages contain a
<body onLoad="javascript: myfunction()">
with "myfunction" doing something that really requires a new interaction with the server, or plays with the browser's History. But again, that's a lot of work, and the user can always disable javascript, or save your page and edit it.


Now, another question is this :
The users go to the site, login, get a cookie, and do some things. Then they logout, and you clear the cookie. Now they use the back button to re-display a page that they could only get before, when they were logged in.
Ok, but is it a problem ?
They can see only pages that they have seen before, when they were logged in, so it should not be a security issue. If they click on any link in that page, since they do not have the cookie anymore, your authentication method should detect that, and re-direct them to the login page, before giving them access (maybe) to the content of that link. Otherwise, it is your authentication setup that is broken.

If it is the user that is concerned that someone else could get to his PC and redisplay confidential pages, then it is their problem, and they should clear the browser cache. You can usually set up the browser to do that automatically when it closes.


André



Malka Cymbalista wrote:
We have created a system for a web site where   a person has to log in,  in order to see the site. Every time a person requests a page in the site, it goes via a perl script which checks to see if there is a cookie which indicates if the person has logged in.
We have put a logout button on the site so that when a person logs out, the cookie is erased. The problem is, if a person logs out and then presses the Back button in the browser, the page is displayed from the cache. If the person goes to a page that he did not previously visit, he gets the login page. But if he goes to a page that he did previously visit, he gets the page from the cache.
We have put the following lines on the page
<META HTTP-EQUIV="Expires" CONTENT="0">
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Cache-Control" CONTENT="no-cache">
but it doesn't seem to help and the page is still cached.  How can I force the page to be read from the server and not displayed from the cache?
We are running Aoache 2.2.6 with mod_perl 2.0.3 on a Linux machine.
Thanks for any help.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx


[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux