Une façon courante de vérifier la prise en charge des cookies est de procéder à une redirection.
Il est conseillé de ne le faire que lorsque l'utilisateur tente de faire quelque chose qui déclenche une session, comme se connecter ou ajouter quelque chose à son panier. Sinon, selon la façon dont vous gérez la situation, vous risquez de bloquer l'accès à l'ensemble de votre site aux utilisateurs - ou aux robots - qui ne prennent pas en charge les cookies.
Tout d'abord, le serveur vérifie les données de connexion comme d'habitude - si les données de connexion sont erronées, l'utilisateur reçoit un retour d'information comme d'habitude. Si elles sont correctes, le serveur répond immédiatement par un cookie et une redirection vers une page conçue pour vérifier la présence de ce cookie - qui peut être simplement la même URL mais avec un indicateur ajouté à la chaîne de requête. Si cette deuxième page ne reçoit pas le cookie, l'utilisateur reçoit un message indiquant qu'il ne peut pas se connecter car les cookies sont désactivés sur son navigateur.
Si vous suivez déjà le modèle Post-Redirect-Get pour votre formulaire de connexion, la définition et la vérification du cookie n'ajoutent aucune demande supplémentaire. Le cookie peut être défini pendant la redirection existante et vérifié par la destination qui se charge après la redirection.
Je vais maintenant vous expliquer pourquoi je ne teste les cookies qu'après une action initiée par l'utilisateur et non à chaque chargement de page. J'ai vu des sites mettre en place un test de cookie sur chaque page, sans réaliser que cela va avoir des effets sur des choses comme les moteurs de recherche qui essaient d'explorer le site. En d'autres termes, si un utilisateur a activé les cookies, le cookie de test est défini une seule fois, de sorte qu'il ne doit supporter une redirection que sur la première page qu'il demande et qu'à partir de là, il n'y a plus de redirections. Cependant, pour tout navigateur ou autre agent utilisateur, comme un moteur de recherche, qui ne renvoie pas de cookies, chaque page pourrait simplement donner lieu à une redirection.
Une autre méthode pour vérifier la prise en charge des cookies est le Javascript - de cette façon, aucune redirection n'est nécessairement nécessaire - vous pouvez écrire un cookie et le relire pratiquement immédiatement pour voir s'il a été stocké puis récupéré. L'inconvénient de cette méthode est qu'elle s'exécute en script sur l'ordinateur de l'utilisateur. côté client - c'est-à-dire que si vous voulez toujours que le message indiquant si les cookies sont acceptés soit renvoyé au serveur, vous devez l'organiser, par exemple avec un appel Ajax.
Pour ma propre application, je mets en place une protection contre les attaques "Login CSRF", une variante des attaques CSRF, en plaçant un cookie contenant un jeton aléatoire sur l'écran de connexion avant que l'utilisateur ne se connecte, et en vérifiant ce jeton lorsque l'utilisateur soumet ses données de connexion. Pour en savoir plus sur le CSRF de connexion, consultez le site de Google. Un effet secondaire de cette méthode est qu'au moment où l'utilisateur se connecte, je peux vérifier l'existence de ce cookie - une redirection supplémentaire n'est pas nécessaire.
0 votes
Où ? Dans le navigateur (côté client) ? Ou dans le serveur ? (quel serveur)
7 votes
Détecter les cookies activés/désactivés dans le code côté serveur, oui.
0 votes
Vous voulez dire utiliser un langage dynamique au lieu de Javascript, les cookies sont toujours ajoutés au navigateur du client, donc... pas de serveur !