[PHP/SQL] Browser cache omzeilen

[Ruffian]

Wij zijn momenteel bezig met een CMS. Deze heeft ook een beheer-gedeelte waarop je dan moet inloggen.

Dit draait allemaal goed en wel, maar we zitten met een klein probleempje. De beheerder logt namelijk wel eens in op een internet café.
Als hij dan uitlogt, komt hij netjes op het inlogscherm uit weer. Het probleem is echter dat als iemand op vorige drukt, hij of zij de gegevens (klant gegevens, bestellingen, etc.) kan zien. De gegevens kunnen niet aangepast worden of iets dergelijks, want zodra je ergens op klikt kom je weer op het loginscherm uit, maar het is natuurlijk wel hinderlijk dat de gegeven zomaar zichtbaar zijn voor iedereen.

Dit "probleem" word veroorzaakt door browser cache, Firefox en Internet Explorer slaan de pagina's op en als je op vorige drukt worden deze direct uit de cache gehaald (er word dus niets naar de server gestuurd), daarom kunnen we vanuit het PHP-script ook niet veel er tegen doen.

De beste oplossing zou natuurlijk zijn om gewoon niet in te loggen in een internet café, maar er moet toch wel iets anders op te vinden zijn?
Vaak is het in internet café's ook zo dat je de instellingen niet mag veranderen, dus kun je de caching niet uitzetten.

We hebben al vanalles geprobeerd met HTTP headers en JavaScripts, maar die worden echter niet uitgevoerd omdat er geen request word gedaan naar de webserver, maar alles uit de cache van de browser word gehaald.
JavaScripts om de browser history te legen zijn we ook al tegengekomen, maar die bieden ook geen uitkomst.

Is er iemand die enig idee heeft hoe we dit kunnen fixen?

[SinergyX]

Als je alles met een Post doet, krijg je toch (iig) bij IE pagina is verlopen? Of bij een logout een dubbele redirect doen met refresh? (klikken ze op vorige komende ze bij de 'eerste' redirect die meteen weer door duwt naar de 2de redirect).

[CHeff]

Dus de volgende html tags heb je ook al geprobeerd?

HTML:

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

[.oisyn]

SinergyX schreef op vrijdag 29 februari 2008 @ 14:15:
Als je alles met een Post doet, krijg je toch (iig) bij IE pagina is verlopen?

En dan gaan ze terug naar het inlogscherm, en zeg je vervolgens dat de gegevens opnieuw moeten worden opgestuurd. Hopla, ingelogd

Of bij een logout een dubbele redirect doen met refresh? (klikken ze op vorige komende ze bij de 'eerste' redirect die meteen weer door duwt naar de 2de redirect).

Dan drukken ze 2x achter elkaar of op die pulldown om 2 stappen terug te gaan.

Dit zijn nou niet echt bepaald goede structurele oplossingen. Wat je moet doen is inloggen mbv een challenge/response, en zorgen dat de verdere identificatie van een sessie middels een sessie-id verloopt. Als je uitlogt kun je het sessie-id bij de server ongeldig maken, en dmv de challenge/response kun je niet opnieuw inloggen door exact dezelfde gegevens op te sturen.

.edit: ah, het gaat om het bekijken van de gegevens. Ja, dan zul je idd moeten zorgen dat ze niet gecached worden, hoewel het besluit om dat wel of niet te doen uiteindelijk toch bij de browser ligt. Je zou ook kunnen denken aan het tonen van de gegevens via Ajax, een Java applet of een Flash plugin.

[ Voor 15% gewijzigd door .oisyn op 29-02-2008 14:25 ]

[Verwijderd]

Volgens mij moet je dit soort problemen wel met HTTP headers kunnen oplossen.
Er wordt altijd een verzoek naar de webbrowser gedaan (in ieder geval één keer om de pagina te downloaden/cachen). Als je in de HTTP headers meegeeft dat die referentie NIET gecached mag worden of dat de cache altijd invalide is zal de browser altijd een verzoek sturen naar de webserver om een nieuwe pagina (omdat de cache invalide is).

Zou je misschien de relevante HTTP headers kunnen posten? Misschien gaat daar iets fout.

code:

Cache-Control: no-cache
Expires: Fri, 29 Feb 2008 13:30:28 GMT
Date: Fri, 29 Feb 2008 13:30:28 GMT

[ Voor 10% gewijzigd door Verwijderd op 29-02-2008 14:32 ]

[SinergyX]

* SinergyX stand corrected

[Ruffian]

Verwijderd schreef op vrijdag 29 februari 2008 @ 14:25:
Volgens mij moet je dit soort problemen wel met HTTP headers kunnen oplossen.
Er wordt altijd een verzoek naar de webbrowser gedaan (in ieder geval één keer om de pagina te downloaden/cachen). Als je in de HTTP headers meegeeft dat die referentie NIET gecached mag worden of dat de cache altijd invalide is zal de browser altijd een verzoek sturen naar de webserver om een nieuwe pagina (omdat de cache invalide is).

Zou je misschien de relevante HTTP headers kunnen posten? Misschien gaat daar iets fout.

Zou je kunnen aangeven hoe ik er voor kan zorgen dat die referenties niet gecached mogen worden? Ik heb al verschillende headers geprobeerd, onder andere de bekende Pragma: No-cache, Cache-control: Private, Expires: 0, etc. etc. Maar ze boden allemaal geen uitkomst.

[Verwijderd]

code:

Cache-control: Private

Bovenstaande geeft aan dat browsers(private) content mogen cachen, maar proxyservers niet (public).

Probeer een soortgelijke header in mijn bovenste post (heb je misschien misgelopen omdat ik de post geedit heb).

[CHeff]

En deze HTTP header dan?

code:

Cache-Control: max-age=0, must-revalidate

[Verwijderd]

Of

code:

Cache-Control:no-store

no-store zou de content alleen moeten 'bewaren' zolang het op het scherm getoond wordt. Wordt er naar een andere pagina gebrowsed zou de browser de content ontraceerbaar moeten maken(verwijderen).

Nooit getest overigens Maar proberen kan nooit kwaad.

[Cavorka]

Ben ik de enige die een 'huh, wtf' in zijn hoofd had toen hij dit hoorde.

Als je met PHP je rechten hebt geregeld, dan kan je met vorige toch niet opeens een pagina bekijken die je alleen kan zien als je bent ingelogd? Lijkt me namelijk dat je bij elke request checked of de gebruiker wel voldoende rechten heeft.

Tenminste, ik kreeg niet voor mekaar wat jij beschreef bij een website van mij, en ik heb geen cache control headers oid. En ik heb volgens mij niets aan mijn cache instellingen van FF veranderd. Ook in IE krijg ik het niet voor mekaar...

Niet echt een nuttige toevoeging misschien, maar dan vraag ik me af hoe het systeem werkt qua rechten.

[Niemand_Anders]

Het gaat om de terug knop. Dat complete scherm staat nog in de cache en wordt zonder tussenkomst van de server aan de gebruiker getoond.

Een simpele workaround is dat je zodra de admin is aangemeld, je het administratie in een popup (tegenwoordig nieuwe tab) toont. Bij het uitloggen zorg je ook dat de popup wordt gesloten. De oplossing van .oisyn om een flash of java applet te gebruiken is ook een goede oplossing.

Overigens vind ik het vreemd dat als jij een expiredate uit het verleden opgeeft, IE nog steeds jouw output cached. Daar hebben wij geen last van.

[gertvdijk]

Het CMS genaamd CMS Made Simple werkt voortreffelijk, want ook bij de terug-knop gebruiken in je browser gaat ie keurig terug naar het login-scherm.
Ik heb zojuist even gekeken wat de truc is, maar het is niet in de vorm van een meta-tag. Wat het wel is ben ik nog niet achter.

[Verwijderd]

Vergeet niet dat een meta-tag niet hetzelfde is als een HTTP header is.

[ Voor 7% gewijzigd door Verwijderd op 29-02-2008 15:28 ]

[gertvdijk]

Verwijderd schreef op vrijdag 29 februari 2008 @ 15:28:
Vergeet niet dat een meta-tag niet hetzelfde is als een HTTP header is.

Goed punt. Dat CMS Made Simple doet het inderdaad met HTTP headers.

code:

Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache

[Verwijderd]

Ik snap het niet helemaal, je doet in het beheer gedeelte toch gewoon iets als

code:

<?php
session_start();
if($_SESSION['loggedIn'] == 1)
{
   // hier beheerstuff
}
else
{
    echo "Woei, niet ingelogd";
}
?>

en als hij uitlogt iets van

code:

<?php
session_start()
// sowieso de laatste en voor de zekerheid mss ook nog de eerste twee
$_SESSION['loggedIn'] = null;
unset($_SESSION['loggedIn']);
session_destroy();
?>

Lijkt me toch dat men dan niet zomaar terugkan gaan en alle gegevens kan zien toch?

[Verwijderd]

Verwijderd schreef op vrijdag 29 februari 2008 @ 22:57:

Lijkt me toch dat men dan niet zomaar terugkan gaan en alle gegevens kan zien toch?

Cache cache cache cache cache cache cache cache cache cache cache cache cache cache.

[Verwijderd]

Verwijderd schreef op vrijdag 29 februari 2008 @ 23:08:
[...]

Cache cache cache cache cache cache cache cache cache cache cache cache cache cache.

Ja dat snap ik, maar als je telkens eerst dynamisch checkt of de gebruiker nog wel is ingelogd en daarna past de content weergeeft wordt het niet gecached of zie ik dat verkeerd?

[Wim-Bart]

Je denkt veel te moeilijk.

Gewoon onder de logout knop een andere pagina laden. Dus zoiets als:

code:

<a href="/logout.php">Afmelden</a>

In de logout.php:

PHP:

<?php
  // Initialize the session.
  // If you are using session_name("something"), don't forget it now!
  session_start();

  // Unset all of the session variables.
  $_SESSION = array();

  // If it's desired to kill the session, also delete the session cookie.
  // Note: This will destroy the session, and not just the session data!
  if (isset($_COOKIE[session_name()])) {
      setcookie(session_name(), '', time()-42000, '/');
  }

  // Finally, destroy the session.
  session_destroy();

  http_redirect("/login.php", array(),  true, HTTP_REDIRECT_PERM);
?>

In de login.php

PHP:

<?php

  $iRand= rand( 1, RAND_MAX );

  $sSessionId= sha1( substr("000000000".$iRand,-10).substr("000000000".(MAX_RAND-$iRand),-10), TRUE );

  SessionId( $sSessionId );
  Session_start();


  ..... Je code

?>

Zodra je ingelogged bent je login status bijhouden, bijvoorbeeld zo:

PHP:

<?php

  Session_Start();

  if ( ValidateUser( $_POST['username'], $_POST['password']) )
  {
     $_SESSION['logged_in']=TRUE;
    http_redirect("/applicatie.php", array(),  true, HTTP_REDIRECT_PERM);
  }
  else
  {
    http_redirect("/login.php", array(),  true, HTTP_REDIRECT_PERM);
  }
?>

En in je applicatie.php:

PHP:

<?php

  Session_Start();
  if ($_SESSION['logged_in']<>TRUE)
  {
    http_redirect("/login.php", array(),  true, HTTP_REDIRECT_PERM);
  }

  ...... de rest van je code

?>

Gedrag is vrij simpel.

1. Gebruiker meld zich aan met een eigen gegenereerde sessionid, dus login.php is een garantie dat er altijd een nieuwe sessie-id wordt gegenereerd.
2. Login status wordt bijgehouden in de sessie.
3. Tijdens het gebruik van de applicatie wordt login status bewaakt.
4. Na afmelden wordt huidige sessie gewist.
5. Er wordt direct een redirect gegeven naar login.php.
6. Bij een back actie op het login scherm wordt de sessie gewist en kom je weer op de loginpagina met weer een nieuwe sessie-id.

De kans dat de zelfde sessie-id wordt verkregen is nihil, en zelfs dan is de sessie met de login-status reeds gewist. Wordt de oude sessie-id achterhaald dan bestaat deze inmiddels al lang niet meer voor php en zal $_SESSION['logged_in'] altijd FALSE zijn.


Overigens kan het nog veel heftiger:

PHP:

<?php

Session_Start();     // We beginnen altijd met een sessie.

$bLoggedIn= (isset($_SESSION["logged_in"])?$_SESSION["logged_in"]:FALSE); // we bepalen de status uit de sessie.

// We dispatchen de applicatie keuzes:
if ($bLoggedIn)
{
    $sFunctie=(isset($_POST["functie"])?$_POST["functie"]:"");
  // Als eerste verwerken we post acties, van bijvoorbeeld formulieren
  switch ($sFunctie)
  {
    case "login":
        $sUsername= (isset($_POST['username'])?$_POST['username']:"");
        $sPassword= (isset($_POST['password'])?$_POST['password']:"");
        if (DoLogin( $sUsername, $sPassword )  // Goed geeft TRUE terug
        {
        if (isset($_COOKIE[session_name()])) 
        {
          setcookie(session_name(), '', time()-42000, '/');
        }
        // Finally, destroy the session.
        session_destroy();
        // Maak een nieuwe sessie aan
        $iRand= rand( 1, RAND_MAX );
        $sSessionId= sha1( substr("000000000".$iRand,-10).substr("000000000".(MAX_RAND-$iRand),-10), TRUE );
             SessionId( $sSessionId );
        Session_start();
        $_SESSION["logged_in"]=TRUE;
        // Ga nu naar de applicatie toe
        Application("titelscherm");
        }
        else
        {
            DisplayLoginScherm();
      }
      break;
    case "verwerwerkorder":
      Application("verwerkorder");
      break;
    case ........................
      /*
        Hier case statements voor overige post acties
      */
    default:
      /*
        Er zijn ook GET acties voor niet formulier geënte onderdelen
      */
      // Functie kan gevuld zijn wanneer deze hierboven niet is afgevangen.
      // Dus proberen we die te verwerken Anders doen we gewoon een GET
      if ($sFunctie<>"")
      {
        $sFunctie= (isset($_GET["functie"])?$_GET["functie"]:"");
      )
      switch ($sFunctie)
      {
        case "titeldscherm":
          Application("titelscherm");
          break;
        case "orderscherm":
          Application("orderscherm");
          break;
            case ........................
            /*
                Hier case statements voor overige get acties
            */            
        default:
          /*
            Een situatie waarin het allemaal niet zo goed gaat, een onbekende functie.
            En dan gaan we gewoon weer inloggen
          */
          $_SESSIE["logged_in"]=FALSE;
          DisplayLoginScherm();
          break;
      }
      break;
  }
}
else
{
  /*
    We zijn niet ingelogged.
    Hieronder dumpen we het loginscherm, met daarin een hidden veld met de naam
    functie die de waarde "login" heeft.
  */
  DisplayLoginScherm();
}

function Application( $sFunctie )
{
    switch ($sFunctie)
    {
        case .......:
          break;
        case .......:
          break;
        etc.
    }
}
?>

[ Voor 80% gewijzigd door Wim-Bart op 01-03-2008 01:56 ]

[gertvdijk]

Wim-Bart schreef op zaterdag 01 maart 2008 @ 01:07:
Je denkt veel te moeilijk.

En jij zou het eens uit moeten proberen voordat je begrijpt wat jij niet inziet hier, getuige je punt hieronder.

Wim-Bart schreef op zaterdag 01 maart 2008 @ 01:07:

• Bij een back actie op het login scherm wordt de sessie gewist en kom je weer op de loginpagina met weer een nieuwe sessie-id.

Dit is namelijk geen actie, maar een simpele cache uit de browser. De hele webserver wordt niet aangesproken nadat er op de back-knop wordt gedrukt. Dàt is de caching die wij bedoelen.

Dus: we moeten de browser vertellen dat hij niet zijn cache mag gebruiken (maar dus weer een hele nieuwe http request moet doen) op het moment dat iemand op de back-knop drukt. En daar hebben we het hier over.

[ Voor 13% gewijzigd door gertvdijk op 01-03-2008 01:37 ]

[Verwijderd]

gertvdijk schreef op zaterdag 01 maart 2008 @ 01:36:
[...]

En jij zou het eens uit moeten proberen voordat je begrijpt wat jij niet inziet hier, getuige je punt hieronder.

[...]

Dit is namelijk geen actie, maar een simpele cache uit de browser. De hele webserver wordt niet aangesproken nadat er op de back-knop wordt gedrukt. Dàt is de caching die wij bedoelen.

Dus: we moeten de browser vertellen dat hij niet zijn cache mag gebruiken (maar dus weer een hele nieuwe http request moet doen) op het moment dat iemand op de back-knop drukt. En daar hebben we het hier over.

Ik snap wat je bedoelt, maar is het niet zo dat dynamische pagina's (dus met PHP) niet gecached worden door de browser by default, maar de hele tijd - vanwege het dynamische aspect - opnieuw worden opgevraagd? Dus wanneer je een stukje php code toevoegd aan zo'n pagina zou hij toch automatisch niet gecached moeten worden? Sorry als ik het topic vervuil, maar ik vraag het me eigenlijk gewoon af (al hoor ik allang in bed te liggen )

[gertvdijk]

Verwijderd schreef op zaterdag 01 maart 2008 @ 01:42:
Ik snap wat je bedoelt, maar is het niet zo dat dynamische pagina's (dus met PHP) niet gecached worden door de browser by default, maar de hele tijd - vanwege het dynamische aspect - opnieuw worden opgevraagd?

Je browser weet niet wat er op de server gebeurt, stuurt gewoon een HTTP request met het adres en krijgt gewoon een heleboel HTTP headers, HTML, etc. terug. Dat krijgt hij ook bij statische pagina's en dus kan hij daarin geen onderscheid maken. Als je dat bijv. zou bepalen op basis van de extensie dan is dat natuurlijk allang achterhaald d.m.v. url rewriting op de server.

[Wim-Bart]

Cache kan je gewoon op je webserver uitschakelen. Content expiratie op direct zetten. Daarnaast kan je inderdaad ook expire meezenden.

Dus:
Buffering aanzetten.
Expire in header meezenden.
Pagina opbouwen.
Pagina flushen naar cliënt.

Daarnaast kan je ook nog een andere functie gebruiken. Zorgen dat er bij iedere pagina een ?parameter=nieuweunikewaarde meegegeven wordt. Bovendien is er één gedrag nooit uit te schakelen en dat is wanneer de cache zodanig is ingesteld dat er nooit op de server gecheked moet worden.

Overigens welke volwassen beheerder duikt in een internet cafe om beheertaken uit te voeren zonder de browser hierna af te sluiten en de cache handmatig te legen????? Discipline noem je dat :-)

[ Voor 4% gewijzigd door Wim-Bart op 01-03-2008 02:05 ]

[Wim-Bart]

gertvdijk schreef op zaterdag 01 maart 2008 @ 01:36:
[...]

En jij zou het eens uit moeten proberen voordat je begrijpt wat jij niet inziet hier, getuige je punt hieronder.

[...]

Dit is namelijk geen actie, maar een simpele cache uit de browser. De hele webserver wordt niet aangesproken nadat er op de back-knop wordt gedrukt. Dàt is de caching die wij bedoelen.

Dus: we moeten de browser vertellen dat hij niet zijn cache mag gebruiken (maar dus weer een hele nieuwe http request moet doen) op het moment dat iemand op de back-knop drukt. En daar hebben we het hier over.

Probeer maar eens op een http redirect in de header uit te komen...... De redirect uit de cache is sneller dan iemand kan klikken......

[TheDane]

Jezes wat een gedoe allemaal. Geef je beheerder gewoon een schop onder z'n reet dat ie OF niet in een internet cafe moet gaan zitten adminnen, OF leer hem hoe ie in zo'n internet cafe de browser cache kan legen. Je mag van een eindgebruiker best wat common sense en verantwoordelijkheidsgevoel verwachten.

[Verwijderd]

Verwijderd schreef op zaterdag 01 maart 2008 @ 00:49:

Ja dat snap ik,

Nee, dat snap je niet. Je vertrouwt de server om te zorgen dat de client niet cachet? Vertrouw je als server dat een client niet cachet? Die headers zijn alleen maar een suggestie voor de client, niemand geeft de garantie dat wat je naar de client stuurt maar één keer gezien kan worden. Het is de gebruiker die zichzelf ervan moet overtuigen dat hij geen vertrouwelijke gegevens achterlaat.

[storeman]

Het volgende heeft voor mij nog nooit problemen opgeleverd, het probleem dat de TS omschrijft wordt volgens mij met behulp van deze twee regels ondervangen:

PHP:

header("Cache-Control: no-cache, must-revalidate");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");

Deze dienen op iedere pagina verstuurd te worden. Na het toevoegen een keer een harde refresh doen, zodat de cache leeg is en de nieuwe wordt gedownload incl headers, geeft het nooit meer problemen.

[Ruffian]

PHP:

header('Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0');
header('Pragma: no-cache');
header('Expires: Thu, 19 Nov 1981 08:52:00 GMT');

That did the trick... De browser laat nu bij een ram op de vorige-knop ook gewoon het login formulier zien.

Misschien niet de meest ideale oplossing, maar voor nu werkt het, in zowel Firefox, IE 7 en IE 6. Een internet café zal vaak IE 6 of misschien IE 7 hebben geïnstalleerd.

[? ?]

..

[ Voor 113% gewijzigd door ? ? op 25-01-2013 09:52 ]

[MarkvE]

Je kunt toch gewoon het beste een logout link maken die een request maakt om uit te loggen en het browser venster uitschakeld met: window.close ();?

Dan ligt de verantwoordelijkheid voor het uitloggen bij de beheerder (wat altijd zo is) en kan hij er niet onderuit om het venster niet te sluiten na het uitloggen, want dit gebeurt automatisch. Hierdoor heb je het hele cache probleem ook opgelost, want het venster is gesloten en het cache kan niet meer worden opgevraagd voor een volgende/vorige.

Overigens kun je op een computer altijd nog de caches bekijken door de tempdir van de browser door te bladeren want dat zijn gewoon HTML en images die daarin staan (dit kan tenminste in Internet Explorer, in Firefox gaat dit volgens mij moeilijker of niet) en dit hangt dus weer van de computer in het internetcafé af of de gebruiker dit kan doen (meestal niet).

[Jochemmol]

Ik zelf ben dit probleem ook altijd tegen gekomen. Ik zag eerder al de oplossing die ik gebruikt.

Tegen cach gebruik ik altijd de datum en tijd mee in de query string. maar daarmee los je jou prbleem niet op.

Wat ik daarom altijd doe is in elke pagina dat de gebruikers komen checken of de session/cookie bestaat. Of te wel kijken of er een geldige inlogsessie is. Zoniet dan redirect naar inlog pagina. Volgens mij is dat de oplossing

[ Voor 4% gewijzigd door Jochemmol op 11-03-2008 15:39 ]