Comparaison des cookies et des sessions-javaDidacticiel-php.cn

1. La différence entre le mécanisme de cookie et le mécanisme de session

Plus précisément, le mécanisme de cookie utilise une solution qui maintient l'état côté client, tandis que le mécanisme de session utilise une solution qui maintient l'état côté serveur.
Dans le même temps, nous voyons également 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é. identité, mais en fait il existe d'autres options.
2. La différence entre les cookies de session et les cookies persistants
Si le délai d'expiration n'est pas défini, cela signifie que le cycle de vie de ce cookie est pendant la session du navigateur. Tant que la fenêtre du navigateur est fermée, le cookie. va disparaître. Ces cookies qui durent pendant toute la durée de la session de navigation sont appelés cookies de session. Les cookies de session ne sont généralement pas stockés sur le disque dur mais en mémoire.
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 seront toujours valides 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 ont différentes manières de gérer les cookies stockés en mémoire.
3. Comment mettre en œuvre la connexion automatique
Lorsqu'un utilisateur s'inscrit sur un site Web, il recevra un cookie avec un identifiant unique. Lorsque le client se reconnecte ultérieurement, cet ID utilisateur est automatiquement renvoyé et le serveur le vérifie pour déterminer s'il s'agit d'un utilisateur enregistré avec une connexion automatique sélectionnée, permettant à l'utilisateur d'accéder aux ressources sur le serveur sans donner de nom d'utilisateur et de mot de passe explicites.
4. Comment personnaliser le site selon les préférences de l'utilisateur
Le site Internet peut utiliser des cookies pour enregistrer les souhaits de l'utilisateur. Pour des paramètres simples, le site Web peut directement stocker les paramètres de la page dans des cookies pour compléter la personnalisation. Cependant, pour des personnalisations plus complexes, le site Web n'a besoin que d'envoyer un identifiant unique à l'utilisateur, et la base de données côté serveur stocke les paramètres de page correspondant à chaque identifiant.
5. Envoi de cookies
1. Créez un objet Cookie
2. Définissez la date d'expiration maximale
3. Mettez le cookie dans l'en-tête de réponse HTTP
Si vous créez un cookie et ajoutez-le Envoyé au navigateur, il s'agit par défaut d'un cookie de session : il est stocké dans la mémoire du navigateur et est supprimé après la sortie du navigateur par l'utilisateur. Si vous souhaitez que le navigateur stocke le cookie sur le disque, vous devez utiliser maxAge et donner une durée en secondes. La définition de l'âge maximum sur 0 demande au navigateur de supprimer le cookie.
Pour envoyer des cookies, vous devez utiliser la méthode addCookie de HttpServletResponse pour insérer le cookie dans un en-tête de requête HTTP Set-Cookie. Étant donné que cette méthode ne modifie aucun en-tête Set-Cookie spécifié précédemment, mais crée un nouvel en-tête, nous appelons cette méthode addCookie au lieu de setCookie. N'oubliez pas également que les en-têtes de réponse doivent être définis avant que le contenu du document ne soit envoyé au client.
6. Lecture des cookies
1. Appelez request.getCookie
Pour obtenir les cookies envoyés par le navigateur, vous devez appeler la méthode getCookies de HttpServletRequest. Cet appel renvoie un tableau d'objets Cookie, correspondant au. Requête HTTP. La valeur saisie dans l'en-tête Cookie.
2. Parcourez le tableau et appelez la méthode getName de chaque cookie jusqu'à ce que le cookie qui vous intéresse soit trouvé
Les cookies sont liés à votre hôte (domaine), pas à votre servlet ou à votre page JSP. Par conséquent, même si votre servlet ne peut envoyer qu'un seul cookie, vous pouvez également recevoir de nombreux cookies sans rapport.
Par exemple :
String cookieName = « userID »;
Cookie cookies［] = request.getCookies();
if (cookies!=null){
for(int i=0 ; je
Cookie cookie = cookies［i］;
if (cookieName.equals(cookie.getName())){
doSomethingWith(cookie.getValue());
}
}
>
7. Comment utiliser les cookies pour détecter les nouveaux visiteurs
A. Appelez HttpServletRequest.getCookies() pour obtenir le tableau Cookie
B. Récupérez en boucle si le cookie avec le spécifié. le nom existe et si la valeur correspondante est correcte
C. Si tel est le cas, quittez la boucle et définissez la marque distinctive
D Déterminez si l'utilisateur est un nouveau visiteur en fonction de la marque distinctive et effectuez différentes opérations<.>8. Erreurs courantes dans l'utilisation des cookies pour détecter les nouveaux visiteurs
On ne peut pas supposer que l'utilisateur est un nouveau visiteur simplement parce qu'un élément de données spécifique n'existe pas dans le tableau de cookies. null, le client peut être un premier visiteur, ou cela peut être le résultat de la suppression ou de la désactivation des cookies par l'utilisateur
Cependant, si le tableau n'est pas nul, il indique uniquement que le client a visité votre site Web ou. domaine, et cela ne signifie pas qu'ils ont visité votre servlet. D'autres servlets, pages JSP et applications Web non Java peuvent définir des cookies. En fonction des paramètres du chemin, tout cookie peut être renvoyé au navigateur de l'utilisateur
Le correct. L'approche consiste à déterminer si le tableau de cookies est vide et si l'objet Cookie spécifié existe et que la valeur est correcte
9. Utiliser les cookies
Les attributs font partie de l'en-tête envoyé du serveur au navigateur. ; mais ils ne font pas partie de l'en-tête renvoyé par le navigateur au serveur.
Par conséquent, en plus du nom et de la valeur, les attributs du cookie s'appliquent uniquement au navigateur envoyé par le serveur au client ; le cookie côté serveur du navigateur ne définit pas ces attributs
.Par conséquent, ne vous attendez pas à utiliser cet attribut dans les cookies obtenus via request.getCookies. Cela signifie que vous ne pouvez pas implémenter la modification des valeurs des cookies simplement en définissant l'âge maximum du cookie, en l'émettant, en recherchant le cookie approprié dans le tableau d'entrée suivant, en lisant sa valeur, en la modifiant et en l'enregistrant dans le cookie. .
10. Comment utiliser les cookies pour enregistrer le nombre d'accès de chaque utilisateur
1 Obtenez la valeur du cookie dans le tableau de cookies qui est spécifiquement utilisé pour compter le nombre de visites des utilisateurs
2. valeur en type int
3. Ajoutez 1 à la valeur et recréez un objet Cookie avec le nom d'origine
4. Réinitialisez la date d'expiration maximale
5. Sortez le nouveau cookie
11. Le différentes significations de session dans différents environnements
Session, souvent traduite par conversation en chinois, sa signification originale fait référence à une série d'actions/messages qui ont un début et une fin. Par exemple, passer un appel téléphonique est une série de processus. de décrocher le téléphone à la numérotation jusqu'à raccrocher le téléphone, ce qui peut être appelé une session.
Cependant, lorsque le mot session est associé aux protocoles réseau, il implique souvent deux significations : "orienté connexion" et/ou "maintien de l'état".
La sémantique de session dans l'environnement de développement Web a été élargie. Sa signification fait référence à un type de solution utilisée pour maintenir l'état entre le client et le serveur. Parfois, Session est également utilisé pour désigner la structure de stockage de cette solution.
12. 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 les informations.
Mais 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 un identifiant de session - appelé identifiant de session. Si elle contient déjà un identifiant de session, cela signifie que cela a déjà été fait. Si le client a créé une session, le serveur récupérera la session et l'utilisera en fonction de l'ID de session (s'il ne peut pas être récupéré, il pourra en créer une nouvelle. Cela peut se produire lorsque le serveur a supprimé l'objet de session correspondant à. l'utilisateur, mais l'utilisateur artificiellement. Un paramètre JSESSION est ajouté à l'URL demandée).
Si la demande du client n'inclut pas d'identifiant de session, une session sera créée pour ce client et un identifiant de session associé à cette session sera généré. Cet identifiant de session sera renvoyé au client pour stockage dans cette réponse.
13. Plusieurs façons de sauvegarder l'identifiant de session
A. L'identifiant de session peut être enregistré à l'aide de cookies, de sorte que lors de l'interaction, le navigateur puisse envoyer automatiquement cet identifiant au serveur selon les règles.
B． Étant donné que les cookies peuvent être artificiellement désactivés, il doit exister d'autres mécanismes pour toujours transmettre l'identifiant de session au serveur lorsque le cookie est désactivé. Une technique souvent utilisée est appelée réécriture d'URL, qui consiste à ajouter l'identifiant de session à la fin de l'URL. chemin Il existe deux manières d'ajouter, l'une sous forme d'informations supplémentaires au chemin de l'URL et l'autre sous forme de chaîne de requête ajoutée à la fin de l'URL. Le réseau conserve son état tout au long de l'interaction, et cet identifiant de session doit être inclus à la fin de chaque chemin que le client peut demander.
C. Une autre technique est 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.
Quand la session est-elle créée ?
Une erreur courante est de penser que la session est créée lorsqu'un client y accède. Cependant, le fait est que ce n'est qu'après un programme côté serveur (comme Servlet). ) appelle HttpServletRequest.getSession(true) De telles instructions seront uniquement créées.
15. Quand la session sera-t-elle supprimée ?
La session sera supprimée dans les circonstances suivantes :
A. Le programme appelle HttpSession.invalidate()
B． L'intervalle de temps depuis le dernier identifiant de session envoyé par le client dépasse la durée de validité maximale de la session
C. Le processus serveur est arrêté
Notez encore une fois que la fermeture du navigateur invalidera uniquement le cookie de session stocké dans la mémoire du navigateur client, mais n'invalidera pas l'objet de session côté serveur.
16. Quels sont les inconvénients de la réécriture d'URL ?
Utilisez la réécriture d'URL pour toutes les URL, y compris les hyperliens, les actions de formulaire et les URL redirigées. Chaque URL qui fait référence à votre site, ainsi que celles qui sont renvoyées à l'utilisateur (même par des moyens indirects, comme le champ Localisation dans une redirection de serveur), ajoute des informations supplémentaires.
Cela signifie que vous ne pouvez pas avoir de pages HTML statiques sur votre site (au moins les pages statiques ne peuvent pas avoir de liens vers les pages dynamiques du site). Par conséquent, chaque page doit être générée dynamiquement à l'aide de servlets ou de JSP. Même si toutes les pages sont générées dynamiquement, si l'utilisateur quitte la session et revient via des signets ou des liens, les informations de session seront perdues car le lien stocké contient des informations d'identification incorrectes - l'ID de SESSION derrière l'URL a expiré.
17. Quels sont les inconvénients de l'utilisation de champs de formulaire masqués ?
Cette méthode ne peut être utilisée que lorsque chaque page est générée dynamiquement par la soumission du formulaire. Cliquer sur un lien hypertexte classique ne génère pas de soumission de formulaire, donc les champs de formulaire masqués ne peuvent pas prendre en charge le suivi de session habituel et ne peuvent être utilisés que dans une série d'opérations spécifiques, telles que le processus de paiement d'une boutique en ligne
18. Suivi de session De base étapes
1. Accédez à l'objet session lié à la requête en cours
2. Rechercher des informations liées à la conversation
3. Stocker les informations de session
4. Supprimer les données de session
19. La différence entre getSession()/getSession(true) et getSession(false)
getSession()/getSession(true) : renvoie la session lorsque la session existe, sinon créez une nouvelle session et return L'objet
getSession(false) : Renvoie la session lorsque la session existe, sinon la session ne sera pas créée et null sera renvoyé
20. Comment associer des informations à la session
SetAttribute remplacera tout valeur précédemment définie ; si vous souhaitez supprimer une valeur sans fournir de remplacement, vous devez utiliser RemoveAttribute. Cette méthode déclenchera la méthode valueUnbound de toutes les valeurs qui implémentent l'interface HttpSessionBindingListener.
21. Existe-t-il des restrictions sur le type d'attributs de session
Habituellement, le type d'attributs de session doit uniquement être Objet. Sauf les types nuls ou basiques, tels que int, double, boolean.
Si vous souhaitez utiliser une valeur de type de base comme attribut, vous devez la convertir en objet de classe encapsulé correspondant
22. Comment supprimer les données de session
A. Supprimez uniquement les données créées par le servlet que vous avez écrit :
Appelez removeAttribute("key") pour supprimer la valeur associée à la clé spécifiée
B. Supprimer la session entière (dans l'application Web actuelle) :
Appelez invalidate pour supprimer la session entière. Cela entraînera la perte de toutes les données de session de cet utilisateur, pas seulement des données de session créées par notre servlet ou notre page JSP
C. Déconnectez l'utilisateur du système et supprimez toutes les sessions lui appartenant
Appelez logOut pour déconnecter le client du serveur Web et supprimer toutes les sessions associées à l'utilisateur (au plus une par application Web). Cette opération peut affecter plusieurs applications Web différentes sur le serveur.
23. La mauvaise façon d'utiliser isNew pour déterminer si l'utilisateur est un nouvel ou un ancien utilisateur
Méthode booléenne publique isNew() Si la session n'a pas encore eu de contact avec le programme client (navigateur), cette méthode renvoie vrai, ce qui est généralement dû au fait que la session est nouvelle et n'est pas provoquée par une demande entrante du client.
Mais si isNew renvoie false, cela signifie simplement qu'ils ont déjà visité l'application Web, et cela ne signifie pas qu'ils ont visité notre servlet ou notre page JSP.
Étant donné que la session est liée à l'utilisateur, une session peut avoir été créée sur chaque page visitée auparavant par l'utilisateur. Par conséquent, si isNew est faux, cela peut uniquement signifier que l'utilisateur a déjà visité l'application Web. La session peut être créée par la page actuelle ou par une page que l'utilisateur a déjà visitée.
L'approche correcte consiste à déterminer si une clé spécifique existe dans une session et si sa valeur est correcte
24. Quelle est la différence entre l'expiration du cookie et le délai d'expiration de la session
Le délai d'expiration de la session est déterminé par la maintenance du serveur, qui est différente de la date d'expiration du cookie. Premièrement, les sessions sont généralement basées sur des cookies résidents en mémoire, qui ne sont pas des cookies persistants et n'ont donc pas de date d'expiration. Même si le cookie JSESSIONID est intercepté, une date d'expiration lui est fixée et envoyée. Les sessions de navigateur et les sessions de serveur peuvent également être très différentes.
25. Les cycles de vie du cookie de session et de l'objet de session sont-ils les mêmes ?
Lorsque l'utilisateur ferme le navigateur, bien que le cookie de session ait disparu, l'objet de session est toujours enregistré côté serveur
26. Tant que le navigateur est fermé, la session disparaîtra
Le programme envoie généralement une instruction pour supprimer la session lorsque l'utilisateur se déconnecte. Cependant, le navigateur n'informe jamais activement le serveur qu'il sera fermé avant la fermeture, donc. le serveur ne le fait tout simplement pas. Il n'y aura aucune chance de savoir que le navigateur a été fermé. Le serveur conserve cet objet de session jusqu'à ce qu'il soit inactif pendant un intervalle défini.
La raison de cette idée fausse est que la plupart des mécanismes de session utilisent des cookies de session pour enregistrer l'identifiant de session après la fermeture du navigateur, l'identifiant de session disparaît et l'identifiant de session d'origine ne peut pas être retrouvé lors de la nouvelle connexion au serveur.
Si le cookie défini par le serveur est enregistré sur le disque dur, ou si une méthode est utilisée pour réécrire l'en-tête de requête HTTP envoyé par le navigateur et envoyer l'identifiant de session d'origine au serveur, la session d'origine peut toujours être trouvée lorsque le navigateur est à nouveau ouvert.
Précisément parce que la fermeture du navigateur n'entraînera pas la suppression de la session, obligeant le serveur à définir un délai d'expiration pour la session. Lorsque le temps écoulé depuis la dernière utilisation de la session par le client dépasse ce délai d'expiration, le serveur peut considérer que le temps écoulé depuis la dernière utilisation de la session par le client dépasse ce délai d'expiration. le client s'est arrêté. Lorsque l'activité est active, la session sera supprimée pour économiser de l'espace de stockage.
De là, nous pouvons tirer la conclusion suivante :
La fermeture du navigateur entraînera uniquement la disparition du cookie de session dans la mémoire du navigateur, mais elle ne fera pas disparaître l'objet de session stocké sur le serveur, ni cela le fait disparaître. Les cookies persistants enregistrés sur le disque dur disparaissent.
27. L'ouverture de deux fenêtres de navigateur utilisera-t-elle la même session ou des sessions différentes pour accéder à l'application ?
Généralement, les cookies de session ne peuvent pas être utilisés dans plusieurs fenêtres. Lorsque vous ouvrez une nouvelle fenêtre de navigateur et entrez dans la même page, le système le fera. vous donner un nouvel identifiant de session, afin que l'objectif de notre partage d'informations ne soit pas atteint.
À ce stade, nous pouvons d'abord enregistrer l'identifiant de session dans le cookie persistant (en définissant la durée de validité maximale de la session), puis le lire dans une nouvelle fenêtre pour obtenir l'identifiant de session de la fenêtre précédente. grâce au cookie de session et au cookie persistant combinés, nous pouvons réaliser un suivi de session multi-fenêtres.
28. Comment utiliser la session pour afficher le nombre de visites pour chaque client
Étant donné que le nombre de visites client est une variable entière, les variables de type de base telles que int, double et booléen ne peuvent pas être utilisées dans le type d'attribut. de session. , nous devons donc utiliser ces types de base d'objets de type encapsulés comme valeurs d'attributs dans l'objet de session
Mais comme Integer, c'est une structure de données immuable : elle ne peut pas être modifiée après sa construction. Cela signifie que chaque requête doit créer un nouvel objet Integer, puis utiliser setAttribute pour remplacer la valeur de l'ancien attribut qui existait auparavant. Par exemple :
HttpSession session = request.getSession();
SomeImmutalbeClass value = (SomeImmutableClass)session.getAttribute("SomeIdentifier");
if (value= =null){
value = new SomeImmutableClass (…); // Créer un nouvel objet immuable
}else{
value = new SomeImmutableClass(calculatedFrom(value)); // Créer un nouvel objet après avoir recalculé la valeur
>
session .setAttribute("someIdentifier", value); // Utiliser l'objet nouvellement créé pour écraser l'ancien objet d'origine
29. Comment utiliser les sessions pour accumuler des données utilisateur
Utiliser des structures de données variables, telles que des tableaux,Liste, Carte ou structure de données spécifique à l'application avec des champs inscriptibles. De cette façon, il n'est pas nécessaire d'appeler setAttribute sauf si l'objet est alloué pour la première fois. Par exemple
HttpSession session = request.getSession();
SomeMutableClass value = (SomeMutableClass)session.getAttribute("someIdentifier");
if(value == null){
value = new SomeMutableClass ( …);
session.setAttribute(“someIdentifier”,value);
}else{
value.updateInternalAttribute(…); // Si l'objet existe déjà, mettez à jour ses attributs sans réinitialiser les attributs.
>
30. Traitement différent des objets immuables et des objets modifiables lors de la mise à jour des données de session
Les objets immuables ne peuvent pas être modifiés une fois créés, les valeurs des attributs dans la session doivent donc être modifiées à chaque fois. , vous devez appeler setAttribute("someIdentifier", newValue) pour remplacer la valeur d'attribut d'origine, sinon la valeur d'attribut ne sera pas mise à jour. Puisque l'objet modifiable lui-même fournit généralement une méthode pour modifier ses propres attributs, il doit être modifié à chaque fois. . Lors de la modification de la valeur d'un attribut dans une session, il vous suffit d'appeler la méthode de l'objet modifiable qui modifie ses propres attributs. Cela signifie que nous n'avons pas besoin d'appeler la méthode setAttribute.