I – Les cookies
I-A – Introduction
I-B – Utilisations
I-C – Sécurité
II – Les sessions
II-A – Introduction
II-B – À quoi servent-elles ?
II-C – Fonctionnement
III – Manipuler les sessions
III-A – Mise en garde
Les registers_globals
Les fonctions session_register(), session_unregister(), session_is_registered() et session_unset()
III-B – Débuter une session
III-C – Sauvegarder une variable
III-D – Récupération de données dans une session
III-E – Savoir si une variable appartient à une session.
III-F – Supprimer une variable d’une session
III-G – Détruire une session
III-H – Détruire toutes les variables d’une session
III-I – Regénérer les identifiants de session.
IV – Aller plus loin
IV-A – Utiliser plusieurs sessions dans la même page
IV-B – Configuration liée aux sessions
La transmission de l’identifiant de session
La sécurité des sessions
La durée de vie des sessions
Modifier localement la configuration des sessions
IV-C – Modifier la façon dont sont stockées les données de sessions
IV-D – À savoir
V – Conclusion
V-A – Épilogue
I – Les cookies
I-A – Introduction
Le protocole HTTP est dit « stateless », ou autrement dit sans état. Pour un serveur, chaque requête qu’il reçoit est indépendante de la précédente, ainsi que de la suivante. Un serveur web est « bête » en quelques sortes, il écoute son port, à chaque fois qu’une requête se présente, il la traite, puis passe à la suivante. Ce processus est néanmoins gênant pour une application, car celle-ci a souvent besoin de « se souvenir » d’un (des) paramètre(s) d’un utilisateur.
Un cookie est un petit fichier texte (inoffensif donc), crée par le serveur. En rajoutant l’en-tête Set-cookie, dans sa réponse, le serveur indique au client qu’il souhaite y stocker un cookie. Le client peut décider, ou non, de s’executer et de créer le cookie demandé.
S’il l’accepte, le navigateur client va ensuite joindre le cookie à l’en-tête de toutes ses requêtes vers le même domaine (on verra ça plus précisément). Aux requêtes suivantes, le client rajoute donc l’en-tête HTTP Cookie et le serveur recevant cet en-tête va le transmettre à PHP. Ainsi sur une seule requête HTTP, on ne peut savoir si le client accepte les cookies, ou non. Il va être obligé de réadresser une requête au même serveur qui va cette fois ci regarder s’il a reçu en retour le cookie, ou non. C’est ainsi que si l’utilisateur décide de changer de navigateur entre 2 requêtes, ce ne seront pas les mêmes cookies qui seront envoyés.
Un cookie est cependant limité en taille, 4Ko maximum; et en nombre de cookies; mais ce chiffre est généralement très grand. On comprendra que pour stocker une quantité importante d’informations, le cookie n’est pas la solution.
Il sert dans une grande majorité des cas à identifier un utilisateur, on va voir cela.
I-B – Utilisations
PHP est lié au serveur web, il récupère les cookies à partir que celui-ci lui fournit, il les a a lui-même reçus, par HTTP, du client. Lorsque PHP récupère les cookies en début de traitement, il les place dans un tableau superglobal accessible via $_COOKIE.
PHP peut aussi décider d’envoyer un cookie (si on le lui demande), par la fonction setCookie(name, value, expire).
Il manque des paramètres, ca sera vu dans la section suivante.
Ainsi lors de l’appel à setCookie(), le moteur de PHP va générer les en-tête HTTP appropriés pour nous, en interne.
C’est pour cela qu’on dit que setCookie() doit être appelé avant toute sortie, car un appel à echo, par exemple, demande à PHP d’afficher quelque chose, et l’oblige donc à générer les en-tête HTTP relatifs à cet affichage.
Or après qu’il ait écrit les en-tête et envoyé le contenu du « echo », on ne peut plus faire machine arrière, un appel à setCookie() génèrera donc un warning vous informant que les en-tête de la réponse HTTP ont déja été envoyés : le fameux « Headers already sent » très connu des débutants..
Revenons à setCookie() : tout d’abord il faut nommer le cookie, pour pouvoir le reconnaitre. Ensuite il faut lui attribuer
une valeur, et enfin optionnellement, une date d’expiration.
Si on ne spécifie pas de date d’expiration, le cookie sera stocké dans la mémoire vive du client (en général), et détruit dès la fermeture du navigateur (et non de l’onglet). Ce cas est pratique pour retenir du client un paramètre temporaire, comme son nom, que l’on souhaite afficher sur nos pages.
Si une date est précisée, ca sera un timestamp. Arrivé à la date, le navigateur client efface le cookie.
Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)Sessions et cookies en PHP (508 KO) (Cours PDF)
