Sessions

&reftitle.intro; Le support des sessions de &php; est un moyen de préserver des données entre plusieurs accès. Cela vous permet de créer des applications personnalisées, et d'augmenter l'attrait de votre site. Chaque visiteur accédant à votre page web se voit assigné un identifiant unique, appelé "identifiant de session". Il peut être stocké soit dans un cookie, soit propagé dans l'URL. Le support des sessions vous permet d'enregistrer un nombre illimité de variables qui doivent être préservées entre les requêtes. Lorsqu'un visiteur accède à votre site, &php; va vérifier automatiquement (si est activé) ou sur demande (explicitement avec session_start ou implicitement avec session_register) s'il existe une session du même nom. Si c'est le cas, l'environnement précédemment sauvé sera recréé. Si vous activé , alors vous ne pourrez pas enregistrer d'objets dans votre session tant que la définition de la classe ne sera pas chargée avant le début de la session, pour recréer les objets de votre session. Toutes les variables sont sérialisées après l'exécution du script &php;. Les variables qui sont indéfinies sont marquées comme telles. Lors des accès ultérieurs, elles ne seront pas définies, jusqu'à ce que l'utilisateur le fasse. Quelques types de données ne peuvent pas être linéarisés pour être stockés dans les sessions. Celà inclut les variables de type resource ou les objets avec des références circulaires (i.e. objets qui passent une référence à lui-même à un autre objet). La gestion des sessions a été ajoutée en &php; 4.0. Notez que lorsque vous travaillez avec les sessions, un enregistrement dans la session ne sera pas créé tant que la variable ne sera pas enregistré en utilisant la fonction session_register ou en ajoutant une clé à la variable super-globale $_SESSION. Cela n'est vrai que si vous avez débuté une session en appelant la fonction session_start.

Sessions et sécurité Lien externe : Session fixation Utiliser les sessions ne signifie pas que les données de session ne pourront être vue que par un seul utilisateur. Il est important de garder cela en tête, lorsque vous stockez et affichez des données importantes. Lorsque vous stockez des données dans une session, il faut se demander quels seront les problèmes posés si quelqu'un d'autre accède à cette information, ou comment votre application est affectée si la session est en fait celle d'un autre. Par exemple, si quelqu'un usurpe une session, il peut alors poster un message dans un forum sous une fausse identité. Quelle est la gravité de ce problème? Ou bien, il peut accéder aux commandes d'un client, et même, modifier son panier d'achat. A priori, c'est moins problématique pour un fleuriste que pour un pharmacien. Si vous voulez résoudre ce souci de façon simple, il peut être utile d'activer session.use_only_cookies. Dans ce cas, les cookies devront être activés par le client, sinon, les sessions ne fonctionneront pas. Par conséquent, lorsque vous manipulez des données importantes, il faut exploiter d'autres méthodes pour décider si une session est valide ou pas. Les sessions ne fournissent pas une méthode fiable d'authentification. Les sessions reposent sur un identifiant de session, ce qui signifie que quelqu'un peut voler cet identifiant, rien qu'en volant l'ID. Ce vol peut être rendu très difficile, comme en utilisant les cookies, mais en aucun cas cela sera impossible. Les sessions dépendent aussi de la discipline de l'utilisateur qui referme son navigateur à la fin de la session pour tout clore proprement. De plus, même les cookies de session peuvent être surveillés sur un réseau, ou bien notés par un proxy car ils transitent en clair sur le réseau. Pour remédier à cela, vous devriez implémenter un chiffrage SSL sur votre plate-forme.

&reftitle.required; &no.requirement; Optionnellement, vous pouvez utiliser l'allocation de mémoire partagée (mm), développé par Ralf S.Engelschall, pour stocker votre session. Vous devez télécharger mm et l'installer. Cette option n'est pas disponible pour les environnements Windows. Notez que le module de stockage de session mm ne garantit pas les verrous de sessions en cas d'accès multiples à la même session. Il peut être moins approprié d'utiliser un système de fichiers basé en mémoire partagée (comme tmpfs sur Solaris/Linux ou /dev/md sur BSD) pour stocker les sessions dans des fichiers, car ils ne seront pas proprement verrouillés.

&reference.session.configure; &reference.session.ini;

&reftitle.resources; &no.resource;

&reference.session.constants;

&reftitle.examples; Depuis &php; 4.1.0, $_SESSION est disponible comme variable globale, au même titre que $_POST, $_GET, $_REQUEST, etc. Contrairement à $HTTP_SESSION_VARS, $_SESSION est toujours globale. Par conséquent, vous n'avez pas besoin d'utiliser le mot réservé global avec $_SESSION. Notez que cette documentation a été modifiée pour utiliser $_SESSION. Vous pouvez toujours le remplacer par $HTTP_SESSION_VARS si vous préférez l'ancienne version. Notez également vous devez démarrer votre session en utilisant la fonction session_start avant d'utiliser la variable super-globale $_SESSION. Les clés du tableau $_SESSION sont sujettes aux mêmes limitations que les variables &php; habituelles, c'est à dire qu'elles ne peuvent pas commencer par un nombre, mais commencer par une lettre ou un souligné '_'. Pour plus de détails, reportez-vous à la section sur les variables. Si track_vars est activé et register_globals est désactivé, seuls les éléments du tableau global $_SESSION contiendront les variables enregistrées dans la session. Les variables de sessions relues seront uniquement disponibles dans $_SESSION. L'utilisation de $_SESSION (ou $HTTP_SESSION_VARS avec &php; 4.0.6 et plus ancien) est recommandé pour une meilleure sécurité et un code plus facilement entretenu. Avec $_SESSION, il n'y a pas besoin d'utiliser les fonctions session_register, session_unregister et session_is_registered. Les variables de sessions sont accessibles comme toute autre variable. Enregistrer une variable avec <varname>$_SESSION</varname>. ]]> Retirer une variable de session avec <varname>$_SESSION</varname> et <link linkend="ini.register-globals"><option>register_globals</option></link> inactif. ]]> N'utilisez PAS la fonction unset avec $_SESSION sous la forme unset($_SESSION) sinon, cela rendra impossible d'enregistrement de données dans la session en utilisant la super-globale $_SESSION. Vous ne pouvais pas utiliser les références sur des variables de session car il n'y a aucune manière faisable de restaurer une référence vers une autre variable. Retirer une variable de session avec <varname>$_SESSION</varname> et <link linkend="ini.register-globals"><option>register_globals</option></link> activé, après l'avoir enregistré avec <varname>$_SESSION</varname>. ]]> Si register_globals est activé, alors toutes les variables globales peuvent être enregistrées comme variables de session, et toutes les variables de sessions seront reconstituées comme variables globales. Comme &php; doit savoir quels variables globales sont enregistrées comme variables de sessions, l'utilisateur doit enregistrer les variables avec session_register tandis que $HTTP_SESSION_VARS et $_SESSION ne nécessitent pas session_register. Avant &php; 4.3, si vous utilisez $_SESSION et que vous avez désactivé , n'utilisez pas session_register, session_is_registered ou session_unregister. Si vous activez register_globals, session_unregister doit être utilisé, car les variables de session sont enregistrés comme variables globales lorsque les données de sessions sont relues. Désactiver register_globals est recommandé pour des raisons de sécurité et de performances. Enregistrer une variable avec <link linkend="ini.register-globals"><option>register_globals</option></link> activé ]]> Si register_globals est activé, alors les variables globales et les entrées dans le tableau $_SESSION seront des références sur la même valeur pour les valeurs qui auront été enregistrées avant le démarrage de la session (donc, dans les page précédentes). De plus, si vous enregistrez une nouvelle variable avec la fonction session_register, l'entrée dans l'environnement globale et $_SESSION ne fera pas de référence vers la même valeur jusqu'à la prochaine utilisation de session_start (ceci s'applique à &php; 4.2 est avant seulement). C'est à dire qu'une modification dans les variables globales ne seront pas répercutés dans les entrées de $_SESSION. Il est peu probable que cela ait un impact en pratique, et de plus, cela a été corrigé en &php; 4.3.

Passer l'identifiant de session (session ID) Il y a deux méthodes de propagation de l'identifiant de session : Cookies Par URL Le module de session supporte les deux méthodes. Les cookies sont optimaux, mais comme ils ne sont pas sûrs (tous les internautes ne les acceptent pas), ils ne sont pas fiables. La seconde méthode place l'identifiant de session directement dans les URL. &php; est capable de faire cela de manière transparente, lorsqu'il est compilé avec l'option --enable-trans-sid. Si vous activez cette option, les URL relatives seront modifiées pour contenir l'identifiant de session automatiquement. Alternativement, vous pouvez utiliser la constante SID, qui est définie, si le client n'a pas envoyé le cookie approprié. SID est soit de la forme session_name=session_id ou une chaîne vide. L'option de &php.ini; vous permet de personnaliser le séparateur d'arguments. Pour être complètement en accord avec les spécifications XHTML, spécifiez & ici. Alternativement, vous pouvez utiliser la constante SID qui est toujours définie. Si le client n'envoie pas un cookie de session approprié, il aura la forme session_name=session_id. Sinon, il vaudra une chaîne vide. Ainsi, vous pouvez dans tous les cas l'inclure dans l'URL. L'exemple suivant vous montre comment enregistrer une variable et comment réaliser un lien correct avec une autre page, avec SID. Compter le nombre de passages d'un utilisateur sur une page

Bonjour visiteur, vous avez vu cette page fois.

Pour continuer, cliquez ici.

]]> La fonction strip_tags est utilisé lors de l'affichage du SID dans le but de contrer les attaques XSS. L'affichage du SID, comme montré dans l'exemple ci-dessus, n'est pas nécessaire si a été utilisé pour compiler &php;. Les URL non-relatives sont considérées comme externes au site, et ne recevront pas le SID, car c'est une fuite d'information vers un autre site (envoi d'informations importantes).

Gestion personnalisée des sessions Pour implémenter un stockage en base de données, ou toute autre méthode, vous aurez besoin de la fonction session_set_save_handler pour paramétrer vos propres fonctions de stockage.