1
votes

Comment détruire complètement (je veux dire COMPLÈTEMENT) toutes les données de session et empêcher l'accès en cache?

Je suis actuellement en train de configurer un site Web à l'aide d'un backend de type pay-wall auquel vous vous connectez avec des comptes Microsoft. Actuellement, j'utilise des sessions PHP pour capturer et suivre les requêtes valides.

J'ai réussi à détruire complètement toutes les données de session enregistrées sur le serveur ainsi qu'à renommer et vider les cookies de session (voir code ci-dessous). Malheureusement, cela ne suffit pas, semble-t-il. Je peux toujours accéder à la page en passant l'ancien ID de session via la variable GET et je peux toujours charger la page. Je soupçonne que c'est une version en cache. J'ai essayé d'ajouter des en-têtes php pour éviter cela, mais il est toujours en cours de chargement!

Code de déconnexion:

<?php
if ($_POST) {
    session_id($_POST["SID"]);
    echo(session_id()); //comes out as same as session origin page
    session_start();
    echo("|||"); //to make payoad easier to read lol
    echo($_SESSION["IS_AUTHORIZED"]); //nothing... and var_dump() is NULL?
?>

Code d'en-tête:

<?php
header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
?>

Je m'attendais à pouvoir appuyer sur le bouton de déconnexion et si j'essayais d'accéder manuellement à la page en fournissant l'ancien identifiant de session par la commande GET, j'aurais dû être renvoyé par la page. Y a-t-il un moyen de contourner cela? Peut-être forcer la page à ré-interroger le serveur (si je peux simplement la faire cingler à nouveau sur le serveur, je crois que mon php devrait rebondir la requête? Je dis cela avec une certaine hésitation hahaha )

EDIT:

Ok, donc après de nombreux débogages, j'ai également réduit le problème avec mon code $ _SESSION ["IS_AUTHORIZED"] > variable? Cela ne devrait pas être possible, mais d'une manière ou d'une autre, le script PHP autonome que j'ai écrit pour détruire une session lorsque l'utilisateur se déconnecte, peut exécuter le même session_id () , mais ne peut accéder à aucune des variables de session? ! si je var_dump ($ _ SESSION ["IS_AUTHORIZED"]) , il crache NULL , alors que sur toutes les autres pages, il crache le booléen 0 code> ou 1 ?!?!?! Je suis très confus ... Je suppose que c'est pourquoi je ne peux pas supprimer correctement la session?

Code:

<?php

if ($_POST) {
    session_start($_POST["SID"]);
    $_SESSION[] = array();

    setcookie( session_name(), "", time()-3600, "/" );

    session_destroy();
    session_write_close();
    echo("Session ".$_POST["SID"]." has been destroyed");
}
?>

EDIT 2:

Oh seigneur. Alors maintenant, après quelques bricolages, le script PHP autonome fonctionne et se connecte au bon session_id () et je peux faire tout le session_destroy () , $ _SESSION = array (); bit pour effacer les informations de session. Petit problème cependant, si je rafraîchis la page HTML avec le session_id () comme variable GET, il charge toujours la page? Dit même que la variable `$ _SESSION [" IS_AUTHORIZED "] que je viens de supprimer dans mon script autonome est maintenant de retour et est revenue avant que je ne la supprime? Cela va littéralement à l'encontre de l'intérêt d'utiliser des sessions? Aidez-moi, s'il vous plaît! (Je déteste les sessions php jusqu'à présent, oh mon âme!)


2 commentaires

stockez-vous une référence à la session dans la base de données à tout moment?


Nan. Stocker uniquement les données utilisateur telles que le nom, le prénom, l'adresse e-mail, etc.


4 Réponses :


0
votes

Détruisez le fichier de données de session situé dans le dossier session_save_path () / la directive session.save_path .


1 commentaires

ok, donc pas vraiment sûr de savoir comment faire ça. A cependant réussi à réduire le problème. Il semble que la variable de session que j'utilise ( $ _SESSION ["IS_AUTHORIZED"] pour suivre les connexions et déconnexions refuse tout simplement d'être modifiée ou effacée par mon script de déconnexion. Si j'essaie d'accéder à la page avec le ID de session, echo 'dans le #_SESSION ["IS_AUTHORIZED"] , il apparaît toujours comme 1 Aka vrai?



0
votes
<?php
  session_start() ;
  unset($_SESSION["IS_AUTHORIZED"]);
  session_destroy();
  session_write_close();
  $_SESSION=new array();
  session_regenerate_id(true);
?>

0 commentaires

0
votes

Si vous [royal you, c'est-à-dire les systèmes de cache] stockez des données utilisateur, par commentaire, vous voudrez peut-être inclure le "privé" dans le contrôle du cache. Cependant, étant donné l'état de non implémenté, proxy, et un caniuse moins que bien documenté pour Hypertext Transfer Protocol. Cela ne fait peut-être pas vraiment une différence. Néanmoins, cela semble approprié et en utilisant les directives, les navigateurs sont plus enclins à les implémenter.

https: / /tools.ietf.org/id/draft-ietf-httpbis-cache-00.html#rfc.section.5.2.2.6

Le max-age = 0 est bien implémenté et à moins que les choses ne soient mal configurées en aval du serveur devrait être tout ce qui est nécessaire.

Si les éléments sont mal configurés, malveillants ou se comportent mal ... en ajoutant un? La marque avec une valeur unique le suivant sur l'URL trompe ces mauvaises implémentations pour considérer l'URL comme une page différente. Systèmes de cache cassés ou non, cela force une connexion au serveur pour demander la page.


La directive à revalider que vous utilisez est la bonne pour faire ce que vous demandez. S'il est mis en œuvre en aval?

En toutes circonstances, un cache DOIT obéir à la directive must-revalidate; en particulier, si un cache ne peut atteindre le serveur d'origine pour raison, il DOIT générer une réponse 504 (Gateway Timeout).


0 commentaires

0
votes

Corrigé! Publier simplement pour toute autre personne ayant ce problème.

Tout cela est lié à la commande session_write_close () . Dans ma page HTML qui hébergeait du contenu restreint, j'avais du code PHP qui vérifiait les variables de session pour déterminer la météo ou non pour afficher la page ou la redirection. Évidemment, pour accéder aux variables $ _SESSION [] en premier lieu, j'ai d'abord dû définir session_id ($ _ GET []) , et puis faites la vérification. Malheureusement, je n'ai jamais appelé session_write_close () pour que la page Web ne soit jamais déconnectée du fichier de session. Mon script de déconnexion autonome supprimait en fait $ _SESSION et unset ($ _ SESSION []) fonctionnait. Le problème est que lors de l'actualisation de la page HTML, je suppose qu'il a réenregistré le fichier de session une fois de plus et l'a effectivement recréé.

L'analogie la plus simple à laquelle je pourrais penser pour l'expliquer serait de modifier un document Word et de supprimer le fichier réel alors qu'il était ouvert dans Word, puis de l'enregistrer à partir de Word, de recréer efficacement le document à nouveau.

Il m'a fallu changer le répertoire de sauvegarde pour y accéder et surveiller la façon dont le fichier de session a changé pour le comprendre (bonne technique de débogage btw)

J'espère que cela aidera les futurs codeurs PHP (bonne chance, vous en aurez besoin lol)


0 commentaires