Forum Programmation.web Page précédente du navigateur...

Posté par  .
Étiquettes :
0
3
mar.
2008
Hello,
Je suis confronté à un problème pour lequel je n'ai pas encore trouvé de solution, pourtant, j'ai bien cherché le web, mais sans succès encore.
Je développe beaucoup en php, et je rédige des applications qui font souvent appel à des bases de données postgreSQL.
Pour que seuls les utilisateurs autorisés puissent utiliser ces applications, l'identification se fait en direct sur la base de la façon suivante :
Une page d'accueil vérifie d'abord la validité des informations de connexion, et si elle ne le sont pas, affiche alors un formulaire demandant un nom d'utilisateur et un mot de passe.
Les informations saisies alors sont utilisées pour tenter un appel à pg_connect avec les informaitons fournies par l'utilisateur, et en cas de succès, les-dites informations sont stockées dans une variable de session.
Jusque là, pas de problème.
Ce qui me tracasse, c'est que si l'utilisateur, après avoir fait ce qu'il avait à faire avec la base quitte sur le bouton quitter de l'application (un script php caché derrière le fameux bouton quitter détruit purement et simplement la session), et qu'il clique ensuite sur le bouton "page précédente" de son navigateur, il voit l'application, sans aucune demande d'identification.
Bon, à partir de là, n'importe quel bouton ou lien de l'application cliqué renverra sur la page d'identification, mais je trouve ça dommage que cette page s'affiche en l'état.
J'en arrive à ma question : peut-on empêcher ce comportement ?
Je ne parle pas (forcément) de désactiver l'emploi de la touche incriminée, mais plutôt qu'en cas de retour arrière la page d'identification soit affichée d'entrée ?
Je ne sais pas si ça a une importance, mais le doctype utilisé par les pages html est : PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"

C'est donc du xhtml strict. Et pour ce que j'avais vu (mais j'ai peut-être mal compris), les meta genre pragma no cache et consorts ne sont pas utilisables avec ce doctype.

Merci d'avance pour l'aide que vous pourrez me donner là dessus.

  • # Système de cache

    Posté par  . Évalué à 6.

    Je pense que c'est plutôt le système de cache du navigateur qui lui permet d'afficher la page consultée précédemment sans avoir à retélécharger la page.
    Il y a peut être un moyen de prévenir le navigateur de ne pas mettre les pages en cache en utilisant l'en-tête HTTP Expires ou bien avec un meta tag html du genre :
    <meta name="Pragma" CONTENT="no-cache">

    Etienne

  • # Peut-être...

    Posté par  (site web personnel) . Évalué à 5.

    En fait, que je sache, la page affichée lors du retour en arrière est celle qui est stockée dans le cache du navigateur.

    La seule solution que je verrai pour éviter cela est de dire au navigateur de ne pas mettre tes pages en cache, mais si tu fait ça, il faut le faire pour toutes les pages protégées ce qui n'est pas très propre.

    <meta http-equiv="Pragma" content="no-cache"/>

    Ca c'est un point que j'ai trouvé, un autre point serait de dire au navigateur que la page expire après 0 seconde, ce qui aurait le même effet : pas de cache.

    <meta http-equiv="expires" content="0"/>

    Il ne faut pas oublier que l'interprétation de ces tag dépend du navigateur et de sa configuration, ce n'est en aucun cas un moyen absolu.

    • [^] # Re: Peut-être...

      Posté par  . Évalué à 1.

      Réponse groupée de ma part :
      - Je me doutais bien que ça avait à voir avec le cache, et effectivement il y a bien une différence de syntaxe entre les différentes version d'html pour spécifier les no-cache et consors.
      - j'ai donc mis à jour mes en-têtes de fichier avec les deux meta proposés, mais sans succès.
      Pensant alors que cela provenait du cache du navigateur, je suis allé regarder la configuration de mon konqui : la case "Utiliser le cache" est décochée, donc le cache n'est pas utilisé, et pourtant j'ai toujours ce comportement...
      Donc, j'en suis toujours au même point avec konqueror.
      Par contre, j'ai bien le comportement attendu avec firefox (en tout cas sous linux, il faut que j'essaye sous winwin pour être certain...).
      On peut donc considérer que le point est gagné et que le problème est résolu.
      Un merci tout particulier à l'auteur du message auquel je répond, car il m'a permis (forcé à) vérifier la validité de mes pages, sur le site du w3c, et de corriger quelques erreurs.
      Mes pages sont donc en plus valides à présent !

    • [^] # Re: Peut-être...

      Posté par  . Évalué à 2.

      Méthode un peu bourrine mais qui marche :

      <meta http-equiv="pragma" content="no-cache">
      <meta http-equiv="expires" content="-1">
      <meta http-equiv="cache-control" content="no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, no-transform, pre-check=0, post-check=0, private">
      <meta name="pragma" content="no-cache"/>

      <meta name="expires" content="-1"/>
      <meta name="cache-control" content="no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, no-transform, pre-check=0, post-check=0, private">

      BeOS le faisait il y a 20 ans !

  • # Sessions

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    En utilisant correctement les sessions, avec vérification sur chaque page de la session, je pense que tu peux arriver pas loin de ce que tu veux. Une petite pincée de gestion de cache depuis le serveur (comme mentionné plus haut) et c'est terminé. 100%.

    La gelée de coings est une chose à ne pas avaler de travers.

    • [^] # Re: Sessions

      Posté par  . Évalué à 1.

      Comme déjà dit, c'est exactement ce que je fais.
      Quelques détails supplémentaires, si ça peut aider d'autres que moi :
      Pour les applications que je développe sur ce modèle, je n'ai qu'un seul point d'entrée, un fichier nommé index.php. Tout se passe dans ce fichier :
      - session_start();
      - vérifications diverses et variées pour savoir quelle page afficher (chargées à base d'includes et de requires), et avant d'afficher quelque contenu que ce soit, un require vers une page qui contient un en-tête standard (du début du code html au body), puis inclusion du ou des fichiers sources demandés, et inclusion d'un fichier fermant la page (du /body au /html)...
      Du coup, avec ce système, je n'avais qu'un seul fichier à modifier, c'est celui qui contient le début du code html.
      Voilà....

  • # trucs simples qui permettent de reduire certains risques de tracas

    Posté par  (site web personnel) . Évalué à 2.

    1. double verification de ta session ( via PHP et Javascript qui xmlhttprequestise un PHP de controle )
    2. ton script de logout vide puis detruit $_SESSION
    3. tu mets une durée de vie courte à ta session
    4. tu vérifies que le referer ne soit pas externe à ton site en page profonde identifié
    5. header( "Cache-Control: options,options,options" ) est ton ami ( RFC HTTP/1.1 )
    6. utilise javascript ( php colle un cookie, JS le detruit si il le trouve, et te redirige sur la page de login sinon )

  • # javascript

    Posté par  (site web personnel) . Évalué à 1.

    Pourquoi pas un petit bout de JavaScript pour forcer la réactualisation de la page?
    Genre sur fait un appel sur une page avec une XMLHttpRequest ou equivalent qui vérifie si l'utilisateur est loggé, s'il ne l'est pas tu le redirige.

    • [^] # Re: javascript

      Posté par  . Évalué à 1.

      Le problème d'une solution à base de javascript, c'est que si le surfeur a désactivé le javascript, cette solution n'apporte rien....
      Le coup du no-cache et du expires me semblait bien, il fonctionne (presque) et reste standard (j'avais juste mal lu la spécification sur le site du w3c et du coup mes pages n'étaient plus valide, mais c'est maintenant corrigé grâce à une réponse donnée ci-dessus).
      Le seul navigateur qui ne gère pas ça, à ma connaissance, c'est konqueror qui se fout des directives mises dans l'en-tête http, apparemment, et qui utilise quand même un cache, même quand on lui dit de ne pas le faire....

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.