Admin CliCours
Cours sessions et cookies en PHP, tutoriel & guide de travaux pratiques en pdf.
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
Les cookies
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.
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 …
Sécurité
Comme un cookie peut être vu et modifié par le client, à la main (c’est un fichier texte), on echappera sa sortie si on l’affiche, et on vérifiera correctement sa valeur. On peut le chiffrer ou lui rajouter une somme de controle (md5) pour empêcher sa modification. Le 4ème paramètre de setCookie() est « path ». Il définit le chemin pour lequel le cookie est valable sur ce domaine, et sera donc envoyé par le client. Par défaut, il vaut « / », ce qui veut dire que le cookie sera fournit à tous les chemins du domaine actuel.
Ainsi le client enverra son cookie si il accède à http://monsite.com, mais aussi à (par exemple) http://monsite.com/sql/
Pour limiter le cookie à un dossier en particulier, on lui passe le nom de dossier en 4ème paramètre :
Un cookie envoyé uniquement au repertoire /admin du domaine, et à tous ses sous-repertoires
<?php setCookie('developpez_admin','Bienvenue administrateur',time()+24*3600,'/admin/'); Le cinquième paramètre de setCookie() fait la même chose, mais pour le domaine et les sous-domaines : <?php setCookie('DBA_developpez','Bienvenue DBA',time()+24*3600,'/admin/','sql.monsite.com');
Les sessions
Introduction
La session est un mécanisme qui permet à PHP de garder « en mémoire » un nombre illimité de valeurs entre plusieurs requêtes d’un même utilisateur. Car maintenant qu’on a vu qu’on pouvait garder une trace d’un utilisateur, les sessions viennent palier à un problème des cookies : leur faible capacité de stockage. En effet, les données de session sont un fichier stocké (à l’inverse du cookie) non pas sur le disque du visiteur mais sur le serveur. Ainsi, il est impossible d’avoir accès aux variables de session via Javascript par exemple. De plus, elles ne transitent pas sans arrêt entre le navigateur et le serveur (à la différence des cookies). Une session permet comme le cookie de stocker temporairement des valeurs relatives à un même internaute.
À quoi servent-elles ?
Elles ont plusieurs utilités. De par leur utilisation, on peut pister le visiteur (et établir des statistiques précises) ou transporter aisément des variables de page en page. On les utilise aussi généralement en complément des cookies dans les scripts d’identification, car parfois le client n’accepte pas les cookies, et donc dans ces situations la session remplace parfaitement le cookie, stocke son identifiant et son mot de passe crypté pour que le membre n’ait pas à le répéter sur chaque page.
Fonctionnement
Les sessions permettent de conserver des variables tant que l’internaute reste connecté au site et environ 30 minutes après (en cas de déconnexion du visiteur par exemple mais ce temps dépend de votre hébergeur : renseignez vous grâce à la fonction phpinfo()). sur lui que repose toute la sécurité du compte de l’utilisateur, de manière générale. Il ne s’agit que d’un petit morceau de texte, unique à chaque visiteur, généré aléatoirement et long, en général, de 32 caractères.
Manipuler les sessions
Mise en garde
Les registers_globals Attendez-vous éventuellement à des surprises de taille si les auto globales sont activées sur votre serveur (directive register_globals mise à On dans votre fichier php.ini). Ce comportement est aujourd’hui formellement déconseillé et déprécié ! Que peut-il donc se passer ? La réponse est simple : en plus des problèmes de sécurité évidents que cette configuration peut poser, vous risquez de modifier des variables de session sans même vous en rendre compte. Illustration avec un exemple :
<?php
session_start();
if (ini_get('register_globals') == '1') {
echo 'Vous devriez mettre <b>register_globals</b> à <b>Off</b><br/>';
}
$_SESSION['login'] = 'toto';
$login = 'titi';
// Affiche :
// - 'titi' avec register_globals à On donc modification car dans CE cas
// $_SESSION['login'] et $login représente la même variable
// - 'toto' avec register_globals à Off
echo $_SESSION['login'];
?>
……
Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)Sessions et cookies en PHP (391 KO) (Cours PDF)
