Les variables de session doivent-elles être évitées?
Dans le passé, je comptais beaucoup sur les variables de session, mais j'ai récemment trouvé que beaucoup d'entre elles n'étaient pas nécessaires, en utilisant des choses comme les paramètres de chaîne de requête à la place.
Un de mes collègues refuse d'utiliser des variables de session. Est-ce un objectif réaliste et faut-il éviter les variables de session pour des raisons pratiques? Les variables de session peuvent-elles être complètement évitées (à l'exception des cookies de session pour permettre les connexions) et cela entraînerait-il de meilleures conceptions?
Certaines des raisons pour lesquelles mon collègue ne les utilise pas:
- Nature non typée des variables de session
- Délais d'expiration de session entraînant une perte d'état
- Portée globale de la nature des variables de session
- Équilibrage de la charge des serveurs perdant des sessions (spécifique à .Net?)
- Redémarrage des pools/serveurs d'applications
- Ils sont inutiles
Si vous avez une variable de session dans votre application, demandez-vous ceci:
Lorsque je clique sur le bouton de retour de mon navigateur, quelle valeur dois-je avoir pour ma variable?
Si la réponse est "la valeur actuelle", les variables de session peuvent être utiles. Un exemple serait un panier: vous ne vous attendez pas à ce que des éléments soient supprimés du panier lorsque vous remontez dans l'historique. Il est toujours dans son état actuel.
Si la réponse est "une valeur précédente", vous ne devez pas utiliser de variables de session. Les mauvaises utilisations que j'ai vues incluent le passage d'un paramètre entre les pages. Si je clique sur le bouton Précédent pour revenir à une page, la page n'obtient pas nécessairement le bon paramètre. De plus, si j'ouvre deux onglets, comment mon site va-t-il se comporter alors?
Obtenir le bon comportement du bouton de retour n'est en aucun cas le tout-et-le-tout, mais cela vous aide à penser à un site Web comme une application sans état. En général, je trouve que les utilisations appropriées des variables de session sont rares.
Le protocole HTTP est sans état. Les sessions sont un moyen de préserver l'état du client sur les requêtes HTTP. Vous pouvez choisir de le faire avec la gestion de session intégrée d'une plate-forme ou de le faire vous-même avec des paramètres de chaîne de requête. Dans tous les cas, un concept de session est nécessaire pour de nombreuses tâches.
Votre collègue n'aime probablement pas une implémentation spécifique ou n'a pas utilisé les sessions aux fins prévues. Si vous avez besoin de conserver des informations sur une connexion client spécifique à travers les requêtes HTTP, vous avez besoin d'une certaine forme de persistance de session.
Les problèmes suivants sont spécifiques à l'implémentation:
Nature non typée des variables de session
Nature de la portée globale des variables de session
Équilibrage de charge des serveurs perdant des sessions
Redémarrage des pools/serveurs d'applications
Par exemple, je travaille le plus souvent en PHP et stocke mes informations de session dans une base de données relationnelle. Donc mes variables de session sont tapées. L'équilibrage de charge et les redémarrages du serveur ne causent aucun problème de session.
Celui-ci est plus intéressant:
Délais d'expiration de session entraînant une perte d'état
Les sessions sont le plus souvent conservées via des cookies. Ceux-ci peuvent être supprimés par le client à tout moment. Mais ils peuvent également être conservés via un paramètre de chaîne de requête et donc ne jamais expirer sur le client. Le délai d'expiration du serveur dépend de vous. Donc, même ce problème est spécifique à l'implémentation.
Ne jetons pas le concept entier de sessions simplement parce que nous n'aimons pas une implémentation particulière. Tout bon cadre d'application Web facilitera l'utilisation correcte des sessions pour préserver les connexions des utilisateurs ou conserver tout autre élément spécifique à la visite actuelle de l'utilisateur. L'enregistrement de la base de données d'un utilisateur peut (et devrait) être utilisé pour stocker des éléments qui lui sont spécifiques lorsqu'il est connecté. Les visiteurs anonymes, cependant, peuvent avoir des informations temporaires qui méritent également d'être conservées dans leur session, comme une courte liste de pages récentes visitées ou la préférence de cachez un avis qu'ils ont déjà vu. Généralement, seules des informations temporaires plus petites sont appropriées pour le stockage de session.
D'autres ont fait beaucoup de bons points (que j'éviterai de répéter), mais il y a un aspect de la technique de votre copain qui n'a pas encore été discuté: sécurité.
Il est impossible de savoir quel type de vulnérabilités vous ouvrez sans regarder le code, mais voici quelques choses auxquelles je peux penser du haut de ma tête.
- Fixation de session: Une attaque puissante qui est légèrement plus facile si vous pouvez simplement demander à l'utilisateur de cliquer sur un lien qui contient déjà les informations nécessaires dans l'URL (plutôt que d'essayer d'amener l'utilisateur à utiliser une machine qui a ses cookies correctement définis).
- injection SQL (ou autre entrée malveillante): ne faites jamais confiance à tout ce qui vient de l'utilisateur. Les variables de session ont l'avantage de ne jamais quitter le serveur, donc l'utilisateur ne peut pas les modifier directement. Alors que vous devez nettoyer les données avant de les placer dans la session, vous pouvez toujours faire confiance aux valeurs que vous obtenez par la suite. Si tout est transmis via la chaîne de requête, vous avez BEAUCOUP de validation à faire pour vous assurer que vous n'acceptez pas d'entrée malveillante.
- Corruption des données en utilisant des entrées falsifiées: Similaire à l'injection SQL, combien de données passez-vous d'avant en arrière? À quel point est-ce crucial? Puis-je changer le comportement de votre application en modifiant une valeur dans la chaîne de requête? Puis-je corrompre les données de votre serveur en modifiant les valeurs? Si j'arrive à corrompre les données sur le serveur, cela affectera-t-il les autres utilisateurs? (Si vous avez répondu "non", ma réponse est "êtes-vous sûr? Vous avez beaucoup d'endroits à vérifier.").
Tous ces éléments peuvent toujours se produire lorsque vous utilisez des sessions, mais ils peuvent être beaucoup plus faciles si votre copain ne sait pas ce qu'il fait.
Les variables de session sont comme les anciennes variables globales de base dans une certaine mesure. Il incombe à l'utilisateur de garder une trace d'eux, de leur contenu, de leur portée et de leur utilisation; comme dans les anciennes versions de BASIC. Cela étant dit, pourquoi quelqu'un refuserait-il totalement l'utilisation d'un mécanisme qui est évidemment conçu pour faire partie intégrante et très importante du modèle de programmation (ASP, MVC, etc.)?
La seule mauvaise chose que j'ai rencontrée en utilisant des variables de session, c'est qu'il vous incombe de les suivre, de vous assurer qu'elles sont remplies de données pertinentes et de les éliminer.
N'est-ce pas ce que nous faisons lorsque nous programmons de quelque façon que ce soit?
Je pensais comme votre collègue en raison de mauvaises expériences que j'avais eu des problèmes de débogage liés aux variables de session, qui n'étaient vraiment que de l'incompétence de ma part. Oui, vous pouvez vous débrouiller dans une certaine mesure sans variables de session, en utilisant des chaînes de requête, des champs cachés dans les formulaires et d'autres choses. Cependant, cela devient très rapidement fastidieux de le faire de cette façon si votre application a quelque chose au-delà du flux logique le plus basique pour déterminer l'état. Il y a aussi le risque de sécurité de montrer le fonctionnement interne de votre application via des chaînes de requête et des champs cachés, qui peuvent tous servir de vecteurs d'attaque.
Lorsque vous travaillez avec des variables de session, il vous suffit de garder une trace du moment où elles sont définies et non définies, car cela déterminera le flux logique de l'application. C'est comme la gestion de la mémoire dans un langage comme C.
Notez que cela vient de mon expérience de travail avec PHP sur un projet relativement petit sans framework, les choses peuvent être différentes sur d'autres plateformes mais je pense que le principe général s'applique toujours.
Comme indiqué précédemment, HTTP est sans état et la variable de session le rompt. La conception HTTP sans état facilite la mise en cache des ressources. Pour les ressources accessibles au public.
Il est possible de concevoir un site Web sans variable de session, mais c'est plus difficile. Le plus difficile (à mon humble avis) est la fantaisie de connexion/déconnexion, les schémas d'authentification HTTP ne fournissent pas les outils nécessaires pour s'authentifier via un formulaire HTML (vous pouvez pirater quelque chose avec javascript - XHR to https: // untel: passowrd @ mydomain .com ) et il est encore plus difficile de se déconnecter et d'être compatible avec tous les navigateurs. il y a eu une discussion sur les listes de facturation w3 à ce sujet mais si je me souviens bien, l'idée a été abandonnée.
Pour le reste, vous devriez pouvoir vivre sans variables de session. Vous aurez un certain état sur une base de données, des fichiers ou n'importe où, mais l'utilisation des variables de session devrait être rare.
Si votre utilisateur possède un panier, il s'agit d'une session variable uniquement si l'utilisateur est censé pouvoir naviguer sur deux ordinateurs/navigateur sans partager le panier.