Quel est le principe du contrôle de session php

Qu'est-ce que le contrôle de session ?

Les cookies et les sessions sont tous deux des moyens techniques permettant de suivre l'ensemble du processus de session. Une session est un appel entre l'utilisateur et le serveur via le navigateur.

Pourquoi avons-nous besoin d'un contrôle de session ?

Le protocole HTTP étant sans état, le serveur ne sait pas ce que l'utilisateur a fait la dernière fois, ce qui entrave sérieusement la mise en œuvre d'applications Web interactives. HTTP n'utilise pas de moyens supplémentaires. Le serveur ne sait pas ce que l'utilisateur a fait. Pour ce faire, il doit utiliser des cookies et des sessions. Le serveur peut définir ou lire les informations contenues dans le cookie pour maintenir l'état de la session de l'utilisateur avec le serveur.

Quelle est la différence entre une session et un cookie ?

Emplacement de stockage, politique de confidentialité et sécurité, type de données, période de validité, pression du serveur, prise en charge du navigateur, prise en charge inter-domaines, volume de données.

(1) Le cookie est côté client, et la session est côté serveur

(2) Le cookie est local et peut être modifié à volonté, et la session est plus sécurisé

(3) Le cookie ne prend en charge que la chaîne asciII, doit être décodé. La session prend en charge tous les types de données.

(4) Les cookies sont stockés localement et peuvent être valides en permanence. La session est sur le serveur. Une fois le paramètre valide en permanence, les sessions sur le serveur continueront à s'accumuler, ce qui entraînera un débordement de mémoire.

(5) La session sera enregistrée sur le serveur dans un certain délai. Lorsque l'accès augmente, cela consommera davantage de performances de votre serveur. Si vous envisagez principalement de réduire les performances du serveur, vous devez utiliser des cookies.

(6) Le cookie nécessite la prise en charge du navigateur, la session ne le prend pas en charge.

(7) Le cookie prend en charge le cross-domain, mais la session ne prend pas en charge le cross-domain.

(8) Les quantités de stockage sont différentes.

Recommandations associées : "Tutoriel PHP"

1. Différences dans les types de données

Les cookies ne peuvent stocker que des chaînes ASCII, si l'accès est requis des caractères Unicode. ou les données binaires doivent d'abord être codées. Les cookies ne peuvent pas accéder directement aux objets Java. Pour stocker des informations un peu plus complexes, il est plus difficile d'utiliser des cookies.

La session peut accéder à tout type de données, y compris, mais sans s'y limiter, une chaîne, un entier, une liste, une carte, etc. Les Java Beans ou même toutes les classes, objets, etc. Java peuvent également être stockés directement dans la session, ce qui est très pratique à utiliser. La session peut être considérée comme une classe de conteneur Java.

2. Différences dans les politiques de confidentialité

Les cookies sont stockés dans le lecteur client et sont visibles par le client. Certains programmes sur le client peuvent espionner, copier ou même modifier le contenu du cookie. La session est stockée sur le serveur et est transparente pour le client, il n'y a donc aucun risque de fuite d'informations sensibles.

Si vous choisissez les cookies, une meilleure façon est d'essayer de ne pas écrire d'informations sensibles telles que les mots de passe des comptes dans les cookies. Il est préférable de crypter les informations des cookies comme Google et Baidu, puis de les décrypter après les avoir soumises au serveur pour garantir que seule la personne peut lire les informations contenues dans le cookie. Si vous choisissez Session, ce sera beaucoup plus facile. Quoi qu'il en soit, il est placé sur le serveur et toute confidentialité dans Session peut être efficacement protégée.

3. Différence de période de validité

Quiconque a utilisé Google sait que si vous vous êtes connecté à Google, vos informations de connexion Google seront valides pendant une longue période. Les utilisateurs n'ont pas besoin de se reconnecter à chaque visite, car Google enregistrera en permanence les informations de connexion de l'utilisateur. Pour obtenir cet effet, l'utilisation de cookies serait un meilleur choix. Définissez simplement l’attribut de délai d’expiration du cookie sur un nombre très, très grand.

Étant donné que la session repose sur un cookie nommé JSESSIONID et que le délai d'expiration par défaut du cookie JSESSIONID est -1, la session deviendra invalide tant que le navigateur est fermé, de sorte que la session ne peut pas obtenir l'effet de validité permanente. des informations. Cela ne peut pas être réalisé en utilisant la réécriture d’adresse URL. Et si le délai d'expiration de la session est trop long, plus le serveur accumulera de sessions, plus il sera facile de provoquer un débordement de mémoire.

4. Différences de pression du serveur

La session est stockée côté serveur et chaque utilisateur générera une session. Si de nombreux utilisateurs accèdent simultanément, de nombreuses sessions seront générées, consommant beaucoup de mémoire. Par conséquent, il est peu probable que les sites Web avec des visites simultanées extrêmement élevées, tels que Google, Baidu et Sina, utilisent Session pour suivre les sessions des utilisateurs.

Le cookie est stocké côté client et n'occupe pas les ressources du serveur. Si de nombreux utilisateurs lisent simultanément, Cookie est un bon choix. Pour Google, Baidu et Sina, Cookie peut être le seul choix.

5. Différences dans la prise en charge du navigateur

Les cookies doivent être pris en charge par le navigateur client. Si le client désactive les cookies ou ne prend pas en charge les cookies, le suivi de session sera invalide. Concernant les applications sur WAP, les cookies classiques ne sont d'aucune utilité.

Si le navigateur client ne prend pas en charge les cookies, la réécriture de la session et de l'adresse URL doit être utilisée. Il convient de noter que toutes les URL qui utilisent le programme Session doivent être réécrites, sinon le suivi de session sera invalide. Pour les applications WAP, la réécriture d'adresse Session+URL peut être la seule option.

Si le client prend en charge les cookies, le cookie peut être configuré pour être valide dans cette fenêtre et sous-fenêtres du navigateur (définissez le délai d'expiration sur –1), ou il peut être configuré pour être valide dans toutes les fenêtres du navigateur (définissez le délai d'expiration à un entier supérieur à 0). Mais la session ne peut être valide que dans cette fenêtre de lecteur et ses sous-fenêtres. Si deux fenêtres de navigateur sont indépendantes l'une de l'autre, elles utiliseront deux Sessions différentes. (La session est liée à différentes fenêtres sous IE8)

6. Différences dans la prise en charge inter-domaines

Le cookie prend en charge l'accès inter-domaines. Par exemple, si l'attribut de domaine est défini sur ".biaodianfu. .com", puis " Tous les noms de domaine avec le suffixe " .biaodianfu.com " peuvent accéder à ce cookie. Les cookies inter-domaines sont désormais couramment utilisés sur Internet, comme Google, Baidu, Sina, etc. La session ne prendra pas en charge l'accès aux noms de domaines différents. La session n'est valable que dans le nom de domaine où elle se trouve.

Utiliser uniquement Cookie ou uniquement Session peut ne pas obtenir l'effet souhaité. À ce stade, vous devriez essayer d’utiliser Cookie et Session en même temps. La combinaison de Cookie et Session produira de nombreux effets inattendus dans des projets pratiques.

7. La quantité de données stockées est différente

Les données enregistrées par un seul cookie ne peuvent pas dépasser 4k, et de nombreux navigateurs limitent un site à enregistrer jusqu'à 20 cookies.

Quels sont les scénarios d'utilisation de la session et des cookies ?

Stockez les informations importantes telles que les informations de connexion en tant que SESSION ; si d'autres informations doivent être conservées, elles peuvent être placées dans COOKIE ;

Comment fonctionnent les cookies ?

1. Les cookies sont divisés en deux types

(1) Les cookies persistants stockés dans l'espace du disque dur sous forme de fichiers (le [Mémoriser le mot de passe] et la [Connexion automatique] les fonctions du site Web sont des cookies persistants)

(2) Les cookies temporaires qui occupent de la mémoire dans le navigateur

2 Les cookies utilisent une solution qui maintient l'état du client, qui est un type de session. état sur le mécanisme de stockage du client. Il s'agit d'un petit morceau de texte stocké par le serveur sur la machine locale ou d'une donnée en mémoire, et envoyé au même serveur à chaque requête

Comment fonctionnent les cookies :

Comment. les cookies fonctionnent, ce qui nécessite une base de base du protocole HTTP.

Les cookies ont été décrits pour la première fois dans la RFC2109 (obsolète, remplacée par la RFC2965). Chaque client peut contenir jusqu'à 300 cookies, et chaque nom de domaine peut contenir jusqu'à 20 cookies (en fait, la plupart des navigateurs en ont désormais plus). ceci (par exemple, Firefox a 50) et la taille de chaque cookie peut aller jusqu'à 4K, mais différents navigateurs ont leurs propres implémentations. Pour l'utilisation des cookies, le plus important est de contrôler la taille des cookies, de ne pas mettre d'informations inutiles, et de ne pas mettre trop d'informations.

Quelle que soit la technologie du serveur utilisée, tant que la réponse HTTP renvoyée contient un en-tête sous la forme suivante, il est considéré que le serveur nécessite l'installation d'un cookie :

Set-cookie:name=name;expires=date;path=path;domain=domain

Les navigateurs qui les cookies de support seront En réponse à cela, un fichier cookie est créé et enregistré (il peut également s'agir d'un cookie de mémoire). Chaque fois que l'utilisateur fera une demande à l'avenir, le navigateur devra déterminer si l'un des cookies actuels a expiré (à en juger). en fonction de l'attribut expires) et correspondent à l'attribut path. Les informations du cookie de l'attribut path, le cas échéant, seront ajoutées à l'en-tête de la requête et renvoyées au serveur sous la forme suivante :

Cookie: name="zj"; Path="/linkage"

Le script dynamique sur le Le serveur l'analysera et le traitera en conséquence. Bien sûr, vous pouvez également choisir de l'ignorer directement.

Mécanisme des cookies Les cookies sont de petits morceaux de texte stockés par le serveur sur la machine locale et envoyés au même serveur à chaque requête. Le mécanisme de gestion de l'état HTTP IETF RFC 2965 est une spécification générale des cookies. Le serveur Web envoie des cookies au client à l'aide d'en-têtes HTTP. Sur le terminal client, le navigateur analyse ces cookies et les enregistre dans un fichier local. Il lie automatiquement ces cookies à toute requête adressée au même serveur.

Plus précisément, le mécanisme des cookies utilise une solution qui maintient l'état côté client. Il s'agit d'un mécanisme de stockage de l'état de session côté utilisateur, qui nécessite que l'utilisateur active la prise en charge des cookies côté client. Le rôle des cookies est un effort pour résoudre les défauts apatrides du protocole HTTP.

La distribution des cookies orthodoxes est obtenue en étendant le protocole HTTP. Le serveur ajoute une ligne d'instructions spéciale à l'en-tête de réponse HTTP pour inviter le navigateur à générer le cookie correspondant conformément aux instructions. Cependant, les scripts purement côté client tels que JavaScript peuvent également générer des cookies. L'utilisation de cookies est automatiquement envoyée au serveur en arrière-plan par le navigateur selon certains principes. Le navigateur vérifie tous les cookies stockés. Si la portée déclarée d'un cookie est supérieure ou égale à l'emplacement de la ressource à demander, le cookie est attaché à l'en-tête de requête HTTP de la ressource demandée et envoyé au serveur.

Le contenu du cookie comprend principalement : le nom, la valeur, le délai d'expiration, le chemin et le domaine. Le chemin et le domaine forment ensemble la portée du cookie. Si le délai d'expiration n'est pas défini, cela signifie que la durée de vie de ce cookie est pendant la session du navigateur. Lorsque la fenêtre du navigateur est fermée, le cookie disparaît. Ce type de cookie qui dure pendant toute la durée de la session du navigateur est appelé cookie de session. Les cookies de session ne sont généralement pas stockés sur le disque dur mais en mémoire Bien entendu, ce comportement n'est pas spécifié par la spécification. Si un délai d'expiration est défini, le navigateur enregistrera les cookies sur le disque dur. Si vous fermez et rouvrez le navigateur, ces cookies resteront valables jusqu'à ce que le délai d'expiration défini soit dépassé. Les cookies stockés sur le disque dur peuvent être partagés entre différents processus de navigateur, tels que deux fenêtres IE. Différents navigateurs disposent de différentes méthodes de traitement des cookies stockés en mémoire.

Le mécanisme de session utilise une solution qui maintient l'état côté serveur. Dans le même temps, nous avons également vu que puisque la solution de maintien de l'état côté serveur nécessite également de sauvegarder une identité côté client, le mécanisme de session peut avoir besoin d'utiliser le mécanisme de cookie pour atteindre l'objectif de sauvegarde de l'identité. Session fournit un moyen pratique de gérer les variables globales.

La session est pour chaque utilisateur. La valeur de la variable est stockée sur le serveur. Un identifiant de session est utilisé pour distinguer de quelle variable de session utilisateur il s'agit. Cette valeur est renvoyée au serveur via le navigateur de l'utilisateur lors de l'accès. Lorsque le client désactive les cookies, cette valeur peut également être définie pour être renvoyée au serveur par get.

En termes de sécurité : Lorsque vous visitez un site qui utilise une session et créez un cookie sur votre machine, il est recommandé que le mécanisme de session côté serveur soit plus sûr car il ne lira pas arbitrairement les données stockées du client. . information.

Comment se déroule la séance ?

(1) Par défaut, toutes les informations utilisateur sont stockées sur le disque dur du serveur. Mais vous pouvez utiliser Memcache pour mettre ces données en mémoire.

(2) Lorsque le client envoie une requête au serveur et demande au serveur de générer une session, le serveur vérifiera d'abord s'il y a un session_id dans le cookie du client et s'il a expiré. S'il existe un tel session_id, le serveur récupérera la session du serveur en fonction du session_id contenu dans le cookie. S'il n'existe pas de session_id, le serveur en recréera un. PHPSESSID est une chaîne cryptée et sa génération s'effectue selon certaines règles. Si le même client démarre session_start deux fois, le session_id sera différent.

(3) Étant donné que la solution de maintien de l'état côté serveur doit également enregistrer une identité côté client, le mécanisme de session utilise le mécanisme de cookie pour atteindre l'objectif de sauvegarde de l'identité

(4) Génération de session Le session_id est placé dans le cookie Si l'utilisateur désactive le cookie, la session deviendra-t-elle inutilisable ? Après avoir désactivé les cookies, la session peut bien sûr être utilisée, mais l'identifiant de session peut être obtenu par d'autres moyens. Par exemple, il peut être rooté à la fin de l'URL, ou soumis au serveur sous la forme d'un formulaire. Cela permet au serveur de comprendre l'état du client.

Regardons à nouveau le principe de la session :

(1) Générer un identifiant globalement unique (sessionid)

(2) Ouvrir un espace de stockage de données. Généralement, la structure de données correspondante sera créée dans la mémoire, mais dans ce cas, une fois le système éteint, toutes les données de session seront perdues. S'il s'agit d'un site e-commerce, ce genre d'accident aura de graves conséquences. Cependant, il peut également être écrit dans un fichier ou même stocké dans une base de données. Bien que cela augmente la surcharge d'E/S, la session peut atteindre un certain degré de persistance et est plus propice au partage de session

( 3) Envoyer l'identifiant global unique de la session au client.

mécanisme de session

Le mécanisme de session est un mécanisme côté serveur. Le serveur utilise une structure similaire à une table de hachage (ou peut utiliser une table de hachage) pour enregistrer. information.

Lorsque le programme doit créer une session pour la demande d'un client, le serveur vérifie d'abord si la demande du client contient déjà un identifiant de session (appelé identifiant de session). Si c'est le cas, cela signifie qu'il a déjà été créé. . Ce client a créé une session et le serveur récupérera la session en fonction de l'identifiant de session et l'utilisera (s'il ne peut pas être récupéré, il en créera une nouvelle. Si la demande du client n'inclut pas l'identifiant de session, un). Une session sera créée pour le client et une session avec celle-ci sera générée. L'identifiant de session associé à la session doit être une chaîne qui n'est ni répétée ni facile à trouver. Cet identifiant de session sera créé. être renvoyé au client dans cette réponse pour stockage.

Un cookie peut être utilisé pour enregistrer cet identifiant de session, afin que lors du processus d'interaction, le navigateur puisse afficher automatiquement cette identification au serveur selon les règles. Généralement, le nom de ce cookie est similaire à SEEESIONID. Mais les cookies peuvent être artificiellement désactivés, et il doit exister d'autres mécanismes pour toujours transmettre l'identifiant de session au serveur lorsque les cookies sont désactivés.

Une technique fréquemment utilisée est appelée réécriture d'URL, qui consiste à ajouter l'identifiant de session directement à la fin du chemin de l'URL. Il existe également une technique appelée formulaire de champs cachés. Autrement dit, le serveur modifiera automatiquement le formulaire et ajoutera un champ masqué afin que l'identifiant de session puisse être renvoyé au serveur lorsque le formulaire est soumis.

Cookie et Session peuvent effectuer un suivi de session, mais les principes de réalisation sont différents. Dans des circonstances normales, les deux peuvent répondre aux besoins, mais parfois le Cookie ne peut pas être utilisé, et parfois la Session ne peut pas être utilisée. Ce qui suit est une comparaison des caractéristiques et des situations applicables des deux.

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!