<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="no-cache">
<meta http-equiv="Expires" content="-1">
<meta http-equiv="Cache-Control" content="no-cache">

Are various methods used to tell the browser not to cache the page(or put an expiration date older than the current date).

Stating that using the back browser would ignore the code has been disproved in my personal tests with the code. The fact that the code is at the top of the page has caused my browser to reload the page.

Does this not happen when you run this code etully?

thanks,
json

    OK, etully, I like the javascript checking out approach. And I will make the log in and log out goes to a same script and that script will detect what action the reader really want and then do as what they really want login or logout. These two approaches should be good enough.

    as no-cache set up, I set up most dynamic pages as no-cache. But some dynamic pages of the site, I may want it with cache on. Such as when you register a new account, and submit, and then database finds out either the userid you select is already used and bounced you back to select the new userid. For these pages, I allow the cache, so they don't have to refill out all the information (of course, if the form has sensitive information, i will enforce the no cache). But if I allow the cache on these pages, use no-cache to force the reload will not work on these pages.

    Plus, there are also a lot of pages with static contents only. These pages we usually allow cache, but if we want to switch the buttons, then even these pages I have to make them dynamic pages, every page is a php page then.

    I usually use no-cache just to be on the safe side, and my site are not heavy traffic sites. Well, I may have to explore cache or no-cache in another thread to see which is better practice.

      5 days later

      I've never thought about this before and never had a problem with a website. Come to think of it, I don't think I've ever logged into a website then thought, page back then log-out. How many people would actually do that?

      I've always just done the switching. I personally don't like showing links that are not relevant to the users current state.

        6 days later

        hi.
        Another issue is the following case:

        Say a person is on a protected page, only for logged in users.
        This page will include a protection script handling login/logout.

        At this page is a logout button.
        This will call the protection script to handle logout.
        But when logout is done, and visitor is sent back,
        he will be presented with a login page. At where he just logged out from.

        I have written such a protection script. It is one line of PHP at the top of code, to protect.

        To fix this issue, I had to save REFERING PAGE in SESSION.
        That is The Page that user was BEFORE the protected page.
        When logout is done send user to this.
        If no referal, then send user the default index page.

          i just checked a site I am building (shows entry boxes when not logged in - shows log out when logged in) and if I log out and then hit the back button I stay logged out - dont know what your script does but mine works - no Ajax

          What I am doing is, on log in, build a session basket to hold log in details (I dont store everything so you cant actually log in from a crashed session), then on log out destroy the session - check for session at top of each page and tada, it does what you want

            I did this for the "continue shopping" instead of continue shopping always go back to the default index. use session to remember the last list products page the user was on, and bring them back to the list products page exactly.

            halojoy wrote:

            hi.
            Another issue is the following case:

            Say a person is on a protected page, only for logged in users.
            This page will include a protection script handling login/logout.

            At this page is a logout button.
            This will call the protection script to handle logout.
            But when logout is done, and visitor is sent back,
            he will be presented with a login page. At where he just logged out from.

            I have written such a protection script. It is one line of PHP at the top of code, to protect.

            To fix this issue, I had to save REFERING PAGE in SESSION.
            That is The Page that user was BEFORE the protected page.
            When logout is done send user to this.
            If no referal, then send user the default index page.

              cretaceous wrote:

              i just checked a site I am building (shows entry boxes when not logged in - shows log out when logged in) and if I log out and then hit the back button I stay logged out - dont know what your script does but mine works - no Ajax

              What I am doing is, on log in, build a session basket to hold log in details (I dont store everything so you cant actually log in from a crashed session), then on log out destroy the session - check for session at top of each page and tada, it does what you want

              You didn't keep the cache, so it was not a problem. I am going to head to this road too, if large percent of the site are not static contents and the extra traffic is not a big issue. No cache, force the reload every time. The button then will be showing the right status you are in.

                blackhorse wrote:

                I did this for the "continue shopping" instead of continue shopping always go back to the default index. use session to remember the last list products page the user was on, and bring them back to the list products page exactly.

                My page protection script is a bit different than a normal website authentication.

                The easy way is not bad.
                It will always work to send user to HOME after logout.
                And we save us a lot of headache, when coding.

                🙂

                  blackhorse wrote:

                  You didn't keep the cache, so it was not a problem. ..

                  OK but I havent set any directive explicitly to deal with the cache - could you explain where you believe I have done this?

                  It works on my localhost pc and on a webserver and on different end clients

                    <meta http-equiv="Pragma" content="no-cache">
                    <meta http-equiv="no-cache">
                    <meta http-equiv="Expires" content="-1">
                    <meta http-equiv="Cache-Control" content="no-cache">

                    Or use the php header to set up no cache

                    <?php
                    header ("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past
                    header ("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");
                    // always modified
                    header ("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
                    header ("Pragma: no-cache"); // HTTP/1.0
                    ?>

                      yes but you dont seem to understand - I am not asking how to do it
                      I am asking why you are convinced I have no caching

                      I do not have any expiry or pragma settings at the top of my html

                      when the session is destroyed it destroys the session cookie - if you go 'back' there is no session cookie to be found - so it works without any cache limitations

                      maybe you tried but didnt completely destroy the session or the cached page is picking up variables from the session that may have been exposed

                        OK, then my question, you use php session? If your page is cached, then back button to it will not require reload from the server. So no php will be involved. Just cached page will be used with the old button, right?

                        If you use javascript session (I am not familiar with that) or some other simple client side solutions not ajax, then you may have the answer for my problem.

                        Even google has the problem I addressed.

                        You can try it on google. Go to google homepage sign in with Gmail account. And the google header bar will show button "sign out", and browse in google for a few pages, sign out, the button will show "sign in". Back button to the previous pages, it will still show the old button "sign out" not the new button "sign in".

                          Only way is to turn OFF caching of pages - history, temporary internet files.

                          But will the browser listen to a no-cache command?
                          I think this is not so. Not always.

                          Anyway, whatever the history page shows, you are actually LOGGED OUT.
                          So you will not be able to get any un-authorized dynamic content. Transfered.

                          This issue shows, why it is a good thing to empty cached pages, before you leave your PC.
                          At least if there are others that use same PC. And if there is stuff that is very personal to you.

                            yes - I apologise Blackhorse - because my site does a redirect via an intermediate script it is hard to hit the back button quickly enough - but when multiple clicks are achieved I can get back to the logged in state

                              Write a Reply...