Maison  >  Article  >  développement back-end  >  Contrôle de session PHP : compréhension approfondie des différences et des usages entre cookies et sessions

Contrôle de session PHP : compréhension approfondie des différences et des usages entre cookies et sessions

齐天大圣
齐天大圣original
2020-05-06 07:46:002247parcourir

Quand il s'agit de contrôle de session, la plupart des gens se diront : n'est-ce pas simple ? N'est-ce pas juste COOKIE et SESSION ?

Il s'agit bien de cookies et de sessions, mais savez-vous vraiment comment les utiliser ?

Lors d'un entretien il y a quelques années, j'ai rencontré une question comme celle-ci :

Comment s'assurer que la session expire au bout d'1 heure ?

À ce moment-là, je pensais que ce n'était pas simple, il suffit de régler gc_maxlifetime sur 3600. L'intervieweur de l'époque a déclaré que la réponse était fausse et qu'il n'y avait aucune garantie qu'elle serait invalide après une heure. Bien sûr, il ne m’a pas dit la raison. Plus tard, quand je suis revenu, j'ai cherché attentivement et j'ai découvert.

Avant de répondre à cette question, vulgarisons la connaissance des cookies et des sessions.

La différence et le lien entre COOKIE et SESSION

Différences dans les emplacements de stockage :

  • Cookie stockage Sur le client

  • la session est stockée sur le serveur

La connexion entre eux :

Lorsque le serveur s'ouvre la session, c'est-à-dire après

session_start();

, un identifiant unique (session_id) sera généré et communiqué au client via l'en-tête de réponse. Une fois que le client l'aura reçu, il sera enregistré dans le cookie. Lorsque le client lancera à nouveau une demande, il apportera cette information. Après avoir reçu ces informations, le serveur se rendra dans le répertoire où est stocké le fichier de session pour trouver le fichier correspondant, et après l'avoir trouvé, il extraira les informations de session. C'est grâce à ce mécanisme que le serveur identifie l'identité du client.

Donc, sans cookies, la session n'a aucun sens.

Après avoir introduit la relation entre les cookies et les sessions, parlons de la durée de validité de la session.

Garbage collection de SESSION

Généralement, la période de validité de session par défaut de PHP est de 24 minutes. Si le client n'a pas émis de requête après avoir dépassé ce délai, il peut déclencher le mécanisme de garbage collection et supprimer les fichiers de session expirés. Pourquoi est-ce possible ? Il s’agit du principe du mécanisme des déchets.

Le garbage collection de session PHP est probabiliste et la probabilité est déterminée par session.gc_probability et session.gc_diviso. La probabilité est

session.gc_probability/session.gc_diviso

la gc_probability par défaut de php est de 1, et la valeur par défaut de gc_diviso est de 100, ce qui signifie que la probabilité de déclencher le garbage collection pour chaque requête est de 1/100. Généralement, lorsque notre site Web reçoit un grand nombre de visites, nous pouvons augmenter cette probabilité, par exemple 1/1000, afin de réduire les opérations d'E/S.

Il y a un autre point à noter : Par exemple, le client A a créé une nouvelle session à ce moment (la session est valable 10 minutes). Après 8 minutes, A a envoyé une autre demande. A ce moment-là, sa session expirera-t-elle dans 2 minutes ou 10 minutes ?

La réponse est dans 10 minutes. Car après la deuxième requête, l'heure de modification du fichier de session côté serveur a également changé. Le garbage collection examine l'heure de la dernière modification du fichier de session. Mais réfléchissez-y bien, la durée de validité des cookies correspondante sera-t-elle également mise à jour ? Malheureusement, la durée de validité des cookies ne sera pas mise à jour.

Comment s'assurer que le fichier de session expirera dans une heure ?

Regardons maintenant la question d'origine, comment garantir que le fichier de session expirera dans une heure. Le garbage collection de session est un événement probabiliste, vous ne pouvez donc pas compter dessus.

Ensuite, en définissant la durée de validité du cookie, cela peut-il être fait en définissant cookie_lifetime ?

La réponse est toujours non. Le cookie est côté client. Il a disparu. C'est juste que le cookie ne peut pas être apporté avec la prochaine requête, mais le fichier de session correspondant existe toujours.

En fait, le moyen le plus simple de résoudre ce problème est de sauvegarder la session dans Redis et d'utiliser le délai d'expiration de la clé Redis pour garantir qu'elle expirera dans l'heure. Cette méthode est également une méthode recommandée

Mais si vous ne pouvez utiliser que php, comment pouvez-vous la compléter ?

Vous pouvez définir un horodatage pour chaque session et déterminer l'horodatage avant chaque accès. Collez le code :

<?php
session_start([
    &#39;cookie_lifetime&#39; => 3600,
    &#39;gc_maxlifetime&#39; => 3600
]);

if (isset($_SESSION[&#39;lifetime&#39;]) && $_SESSION[&#39;lifetime&#39;] > time()) {
    // 未过期,更新session的lifetime及cookie的有效期
    $_SESSION[&#39;lifetime&#39;] += 3600;
    $tmpVal = $_COOKIE[session_name()];
    setcookie(session_name(), $tmpVal, time() + 3600, &#39;/&#39;);
} else {
    // 过期删除
    $_SESSION = [];
    if (isset($_COOKIE[session_name()])) {
        setcookie(session_name(), &#39;&#39;, time() - 100, &#39;/&#39;);
    }
    session_destroy();
}

Après avoir lu ce contenu, je pense que tout le monde devrait avoir une compréhension plus approfondie des sessions PHP.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn