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 demandes 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_start($_POST["SID"]);
    $_SESSION[] = array();

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

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

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 le faire cingler à nouveau le serveur, je crois que mon php devrait rebondir la requête? Je dis cela avec une certaine hésitation hahaha )

MODIFIER:

Ok, donc après beaucoup de débogage, j'ai aussi réduit le problème ma variable $_SESSION["IS_AUTHORIZED"]? 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 d'une manière ou d'une autre, 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 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_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?
?>

MODIFIER 2:

Oh Seigneur. Alors maintenant, après quelques bricolages, le script PHP autonome fonctionne et établit des liens vers le bon session_id() et je peux faire tout le bit session_destroy(), $_SESSION = array(); pour effacer les informations de session. Petit problème cependant, si j'actualise la page HTML avec le session_id() comme variable GET, il charge toujours la page? Même si 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!)

1
Graeme Ford 26 janv. 2019 à 18:02

4 réponses

Meilleure réponse

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

Il s'avère que tout 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[<session id passed via GET>]), puis faire la vérification. Malheureusement, je n'ai jamais appelé session_write_close() pour que cette page Web ne soit jamais déconnectée du fichier de session. Mon script de déconnexion autonome supprimait en fait les WAS $_SESSION et unset($_SESSION[<variable name>]) fonctionnant. Le problème est que lors de l'actualisation de la page HTML, je suppose qu'il a réenregistré le fichier de session à nouveau 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
Graeme Ford 28 janv. 2019 à 08:44

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

0
JCH77 26 janv. 2019 à 15:49
<?php
  session_start() ;
  unset($_SESSION["IS_AUTHORIZED"]);
  session_destroy();
  session_write_close();
  $_SESSION=new array();
  session_regenerate_id(true);
?>
0
Bsquare ℬℬ 26 janv. 2019 à 22:08

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, tout ce qui est nécessaire.

Si les choses sont mal configurées, malveillantes 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, il 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?

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

0
Wayne 26 janv. 2019 à 18:52