Comment détecter sur le serveur (côté serveur) si les cookies du navigateur sont désactivés? C'est possible?
Explication détaillée: Je traite une requête HTTP sur le serveur. Je souhaite créer un cookie via l'en-tête Set-Cookie
. J'ai besoin de savoir à ce moment-là si le cookie sera défini par le navigateur client ou si ma demande de définition du cookie sera ignorée.
Envoyez une réponse de redirection avec le jeu de cookies; lors du traitement du test d'URL redirigé (spécial) pour le cookie - s'il s'agit d'une redirection vers un traitement normal, sinon, redirigez vers un état d'erreur.
Notez que cela ne peut vous indiquer que le navigateur a autorisé le cookie, mais pas pour combien de temps. Mon FF me permet de forcer tous les cookies en mode "session", à moins que le site ne soit spécifiquement ajouté à une liste d'exceptions - ces cookies seront supprimés lorsque FF sera fermé, quel que soit le serveur expiré. Et c’est le mode dans lequel je lance FF depuis toujours.
Vous pouvez utiliser Javascript pour accomplir cela
Bibliothèque:
function createCookie(name, value, days) {
var expires;
if (days) {
var date = new Date();
date.setTime(date.getTime() + (days * 24 * 60 * 60 * 1000));
expires = "; expires=" + date.toGMTString();
}
else expires = "";
document.cookie = name + "=" + value + expires + "; path=/";
}
function readCookie(name) {
var nameEQ = name + "=";
var ca = document.cookie.split(';');
for (var i = 0; i < ca.length; i++) {
var c = ca[i];
while (c.charAt(0) == ' ') c = c.substring(1, c.length);
if (c.indexOf(nameEQ) == 0) return c.substring(nameEQ.length, c.length);
}
return null;
}
function eraseCookie(name) {
createCookie(name, "", -1);
}
function areCookiesEnabled() {
var r = false;
createCookie("testing", "Hello", 1);
if (readCookie("testing") != null) {
r = true;
eraseCookie("testing");
}
return r;
}
Code à exécuter:
alert(areCookiesEnabled());
Rappelles toi
Cela ne fonctionne que si Javascript est activé!
Je ne pense pas qu'il existe des moyens directs de vérifier. Le meilleur moyen est de stocker une valeur dans le cookie et d'essayer de la lire et de décider si les cookies sont activés ou non.
Un moyen courant de vérifier la prise en charge des cookies consiste à effectuer une redirection.
C'est une bonne idée de ne le faire que lorsque l'utilisateur essaie de faire quelque chose qui lance une session, telle que la connexion ou l'ajout de quelque chose à son panier. Sinon, en fonction de la manière dont vous le gérez, vous bloquez potentiellement l'accès à l'ensemble de votre site pour les utilisateurs - ou les bots - qui ne prennent pas en charge les cookies.
Premièrement, 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 ce retour comme d'habitude. Si c'est le cas, le serveur répond immédiatement par un cookie et une redirection vers une page conçue pour rechercher 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, ce paramètre et la vérification du cookie n'ajoutent aucune requête supplémentaire. Le cookie peut être défini lors de la redirection existante et vérifié par la destination chargée. après la redirection.
Maintenant, pourquoi je ne teste les cookies qu’après une action de l’utilisateur autre que le chargement de toutes les pages. J'ai vu des sites implémenter un test de cookie sur chaque page, sans se rendre compte que cela aurait des effets sur des éléments tels que les moteurs de recherche qui tentent d'explorer le site. Autrement dit, si les cookies sont activés pour un utilisateur, le cookie de test est défini une fois. Il ne doit donc supporter qu'une redirection sur la première page qu'il demande et, par la suite, aucune redirection. Cependant, pour tout navigateur ou autre agent utilisateur, tel qu'un moteur de recherche, qui ne renvoie pas de cookies, chaque page pourrait simplement entraîner une redirection.
Une autre méthode de vérification de la prise en charge des cookies consiste à utiliser Javascript. Ainsi, aucune redirection n’est 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 est qu’il est exécuté dans un script côté client, c’est-à-dire que si vous souhaitez toujours que le message indiquant si les cookies sont pris en charge revienne sur le serveur, vous devez quand même organiser cela, comme avec un Ajax appel.
Pour ma propre application, j'implémente une protection contre les attaques de type "Login CSRF", une variante des attaques de type CSRF, en définissant 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 lorsqu'il envoie son identifiant de connexion. détails. En savoir plus sur Login CSRF de Google. Un effet secondaire de cela est que, dès lors qu'ils se connectent, je peux vérifier l'existence de ce cookie - une redirection supplémentaire n'est pas nécessaire.
En règle générale, il se peut que vous deviez uniquement vérifier la prise en charge des cookies une fois que l'utilisateur a pris des mesures sur le site, telles que la soumission d'un formulaire de connexion, l'ajout d'un article à son panier, etc.
Pour moi actuellement, la vérification de la prise en charge des cookies va de pair avec la prévention des demandes de type CSRF (falsification de requêtes intersites).
Vous devriez probablement aller ailleurs pour lire plus sur CSRF , mais l’idée sous-jacente est que d’autres sites peuvent tromper ou inciter vos utilisateurs à soumettre une forme cachée de leur choix sur votre propre site. Pour contourner ce problème, définissez un cookie lorsque le visualiseur voit un formulaire, définissez un jeton correspondant en tant qu'élément de formulaire masqué, puis, lors du traitement du formulaire, vérifiez que le cookie et l'élément de formulaire masqué ont été définis et correspondent. S'il s'agit d'une tentative d'attaque CSRF, le site ne pourra pas fournir le champ caché correspondant au cookie de l'utilisateur, car celui-ci ne leur sera pas lisible avec la stratégie de même origine.
Si un formulaire est soumis sans cookie, mais qu'il contient un jeton d'apparence valide, vous pouvez en conclure que l'utilisateur a désactivé les cookies et afficher un message lui indiquant qu'il doit activer les cookies et réessayer. L’autre possibilité, bien sûr, est que l’utilisateur soit victime d’une tentative d’attaque CSRF. Donc, bloquer l'utilisateur lorsque le cookie ne correspond pas aura également pour effet secondaire d'empêcher cette attaque.
J'ai toujours utilisé ceci:
navigator.cookieEnabled
Selon w3schools "La propriété cookieEnabled est prise en charge par tous les principaux navigateurs.".
Cependant, cela fonctionne pour moi lorsque j'utilise des formulaires, où je peux demander au navigateur d'envoyer les informations supplémentaires.
Essayez de stocker quelque chose dans un cookie, puis lisez-le. Si vous n'obtenez pas ce que vous attendez, les cookies sont probablement désactivés.
vérifiez ce code, il vous aidera.
<?php
session_start();
function visitor_is_enable_cookie() {
$cn = 'cookie_is_enabled';
if (isset($_COOKIE[$cn]))
return true;
elseif (isset($_SESSION[$cn]) && $_SESSION[$cn] === false)
return false;
// saving cookie ... and after it we have to redirect to get this
setcookie($cn, '1');
// redirect to get the cookie
if(!isset($_GET['nocookie']))
header("location: ".$_SERVER['REQUEST_URI'].'?nocookie') ;
// cookie isn't availble
$_SESSION[$cn] = false;
return false;
}
var_dump(visitor_is_enable_cookie());
J'utilise une version beaucoup plus simplifiée de la réponse de "balexandre" ci-dessus. Il tente de définir et de lire un cookie de session dans le seul but de déterminer si les cookies sont activés. Et oui, cela nécessite que JavaScript soit également activé. Donc, vous voudrez peut-être une étiquette si vous en voulez une.
<script>
// Cookie detection
document.cookie = "testing=cookies_enabled; path=/";
if(document.cookie.indexOf("testing=cookies_enabled") < 0)
{
// however you want to handle if cookies are disabled
alert("Cookies disabled");
}
</script>
<noscript>
<!-- However you like handling your no JavaScript message -->
<h1>This site requires JavaScript.</h1>
</noscript>
La question de savoir si les cookies sont "activés" est trop booléenne. Mon navigateur (Opera) a un paramètre de cookie par site. En outre, ce paramètre n'est pas oui/non. Le formulaire le plus utile est en fait "session-only", ignorant la date d'expiration des serveurs. Si vous le testez directement après le réglage, il sera là. Demain, ça ne va pas.
De plus, comme il s'agit d'un paramètre que vous pouvez modifier, même vérifier que les cookies ne restent pas vous indique uniquement le paramètre lorsque vous avez testé . J'aurais peut-être décidé d'accepter ce cookie manuellement. Si je continue à être spammé, je peux (et le ferai parfois) simplement désactiver les cookies pour ce site.
Si vous souhaitez uniquement vérifier si les cookies de session (cookies existant pendant toute la durée de la session) sont activés, définissez votre mode de session sur AutoDetect dans votre fichier web.config, le framework Asp.Net écrira un cookie. au navigateur client appelé AspxAutoDetectCookieSupport . Vous pouvez ensuite rechercher ce cookie dans la collection Request.Cookies pour vérifier si les cookies de session sont activés sur le client.
Par exemple. dans votre ensemble de fichiers web.config:
<sessionState cookieless="AutoDetect" />
Ensuite, vérifiez si les cookies sont activés sur le client avec:
if (Request.Cookies["AspxAutoDetectCookieSupport"] != null) { ... }
Sidenote: Par défaut, il est défini sur UseDeviceProfile, qui essaiera d'écrire des cookies sur le client aussi longtemps que le clientprend en chargethem, même si les cookies sont désactivés. Je trouve un peu étrange qu’il s’agisse de l’option par défaut car elle semble en quelque sorte inutile: les sessions ne fonctionneront pas avec les cookies désactivés dans le navigateur du client avec le réglage UseDeviceProfile, et si vous prenez en charge le mode sans cookie pour les clients qui ne les prennent pas , pourquoi ne pas utiliser AutoDetect et prendre en charge le mode sans cookie pour les clients qui les ont désactivés ...
NodeJS - Server Side - Cookie Check Redirect Middleware - Express Session/Cookie Parser
Dépendances
var express = require('express'),
cookieParser = require('cookie-parser'),
expressSession = require('express-session')
Middleware
return (req, res, next) => {
if(req.query.cookie && req.cookies.cookies_enabled)
return res.redirect('https://yourdomain.io' + req.path)
if(typeof(req.cookies.cookies_enabled) === 'undefined' && typeof(req.query.cookie) === 'undefined') {
return res.cookie('cookies_enabled', true, {
path: '/',
domain: '.yourdomain.io',
maxAge: 900000,
httpOnly: true,
secure: process.env.NODE_ENV ? true : false
}).redirect(req.url + '?cookie=1')
}
if(typeof(req.cookies.cookies_enabled) === 'undefined') {
var target_page = 'https://yourdomain.io' + (req.url ? req.url : '')
res.send('You must enable cookies to view this site.<br/>Once enabled, click <a href="' + target_page + '">here</a>.')
res.end()
return
}
next()
}
La propriété cookieEnabled
renvoie une valeur booléenne qui spécifie si les cookies sont activés ou non dans le navigateur.
<script>
if (navigator.cookieEnabled) {
// Cookies are enabled
}
else {
// Cookies are disabled
}
</script>