Vous avez raison, l'état de votre application ne persiste pas d'une requête à l'autre.
Contrairement aux applications de bureau, les applications web ne restent pas initialisées car pour le serveur, à chaque fois cela peut être un autre visiteur, voulant quelque chose de complètement différent. Vous savez qui utilise l'application de bureau, mais vous ne savez pas forcément qui demande la page. Imaginez 10 utilisateurs faisant des choses différentes simultanément sur votre application web ? Vous ne garderiez pas nécessairement toute l'application en cours d'exécution pour chacun de ces visiteurs. Imaginez avec 10 000 visiteurs...
Il y a des façons de conserver des données d'une requête à une autre cependant. L'application sera réinitialisée à chaque fois, oui, mais vous pouvez ensuite recharger l'état de ce que vous faisiez. Cela tourne toujours autour des mêmes méthodes générales :
-
Cookies; Les cookies sont de petits fichiers conservés du côté client et dont le contenu sera disponible à chaque demande pour vous. En PHP, cela est accessible en utilisant la variable $_COOKIE. Dans tous les cas, vous pourriez sérialiser vos instances de classes et les recharger ensuite. Le problème est que vous ne voudriez pas mettre des données sensibles là-dedans car tout le monde peut voir et les modifier.
-
POST ou GET; À chaque requête, vous passez un état dans la requête $_GET (l'URL telle que http://localhost/myscript.php?iamatstep=4. Ou via un $_POST tel qu'en utilisant un champ de saisie masqué dans un formulaire. Ces données pourraient être cryptées et ne faire sens que pour vous, mais néanmoins, vous mettez des données sensibles sur le client et n'importe qui pourrait y toucher.
-
Base de données, Disque; Ou n'importe quoi d'autre sur le serveur. Encore une fois, vous sérialisez vos données dans un fichier par exemple à la fin d'une requête, prêtes à être utilisées à nouveau pour la prochaine requête. Le principal avantage est qu'elles restent sur votre serveur. L'inconvénient est qu'à ce stade, vous ne savez pas quelles données extraire pour quelle demande car il pourrait y avoir plusieurs utilisateurs sur votre application en même temps...
Et voici où intervient la notion de $_SESSION. C'est juste une façon empaquetée d'utiliser tout cela en même temps. Ce n'est pas magique comme c'est souvent perçu par les débutants. Lorsque vous utilisez une session, les données mises dans $_SESSION sont stockées quelque part sur le serveur (normalement dans un fichier dans un répertoire temporaire bien que cela puisse être changé en quelque chose d'autre comme une base de données) et un identifiant unique est attribué à cette session et passé dans un cookie qui suivra le visiteur d'une requête à l'autre. Ainsi, la seule chose du côté du client est un grand nombre dans le cookie. À la demande suivante, le navigateur dit à PHP sur le serveur qu'il s'agit de la session numéro 12345, charge le fichier correspondant s'il existe et les données vous sont à nouveau disponibles. Si les cookies ne sont pas activés, cela pourrait être transmis via un GET ou POST, bien qu'il soit souvent préférable de ne pas y aller (voir la note de session.use_trans_sid).
Il semblerait souvent que sur chacune de vos pages, vous avez besoin d'authentification.
``
Et pour définir la session, cela ressemblerait probablement à ceci :
`
Et enfin, peut-être une page logout.php qui ferait quelque chose comme cela :
` ``