Il semble que la récente mise à jour de Chrome vers la version 83.0.4103.116 a modifié la gestion des cookies.
Je propose une connexion unique à mes utilisateurs qui les connecte à plusieurs sites Web. Similaire à Stackoverflow, je fais une requête AJAX avec Jquery:
// needed for cross-domain request
header('Access-Control-Allow-Origin: https://www.example.com');
header('Access-Control-Allow-Credentials: true');
Et en PHP, j'autorise le domaine:
crossDomain: true,
xhrFields: { withCredentials: true },
Cependant, maintenant cela ne fonctionne plus.
Dans la console de développement, j'ai trouvé un nouvel avertissement avec l'info-bulle:
"Ce cookie défini a été bloqué en raison des préférences de l'utilisateur"
Comment régler ceci?
Mise à jour:
Je vois juste que le Single-Sign-On de Stackoverflow ne fonctionne plus non plus!
PS: Une question connexe suggère de dire à vos utilisateurs de modifier les paramètres de Chrome, à partir de mon PDV, j'aimerais éviter cela. Imaginez simplement SO informer des millions d'utilisateurs pour permettre aux cookies de faire une connexion unique ...
3 Réponses :
Le site qui transmet l' set-cookie tête HTTP set-cookie doit également transmettre le SameSite comme None et également Secure , sinon le cookie n'est pas enregistré et est ignoré.
function setcookieSameSite($name, $value, $expire, $path, $domain, $secure, $httponly, $samesite="None")
{
if (PHP_VERSION_ID < 70300) {
setcookie($name, $value, $expire, "$path; samesite=$samesite", $domain, $secure, $httponly);
}
else {
setcookie($name, $value, [
'expires' => $expire,
'path' => $path,
'domain' => $domain,
'samesite' => $samesite,
'secure' => $secure,
'httponly' => $httponly,
]);
}
}
Avant de le faire, veuillez lire les implications de sécurité: https://blog.heroku.com/chrome-changes-samesite-cookie
Exemple de code PHP ( source ):
Set-Cookie: qa_session=...; SameSite=None; Secure
Pourtant, il y a quelque chose que mon navigateur n'aime pas. Le cookie se présente comme suit: Set-Cookie: JSESSIONID = somevaluehere; path = / my-site-path; SameSite = None; Sécurisé mais le navigateur dit toujours qu'il ne veut pas le définir. Remarque: le re / rsp est dans une iframe.
Je l'ai corrigé: le problème était que je testais en mode Incognito dans Chrome. En outre, il y avait un paramètre par défaut dans Chrome qui spécifiait que le mode de navigation privée ne devrait pas accepter les cookies tiers. Donc, j'ai activé l'option et les cookies sont maintenant enregistrés.
pour PHP 5.6.40 Si vous n'avez aucun problème à reconstruire le binaire PHP, j'ai réussi à porter cette fonctionnalité de PHP 7.3 à PHP 5.6.40, et il y a maintenant une pull request. Voir la réponse complète ici: stackoverflow.com/a/64960472/1641763
Si vous ne pouvez reproduire cela que dans Incognito et que la réponse de Pierre Pretorius n'a pas aidé, vous êtes probablement frappé par un changement dans Chrome 83 où les cookies tiers sont bloqués par défaut en mode Incognito. Voir https://angel.co/today/stories/chrome-83-arrives-with-redesigned-security-settings-third-party-cookies-blocked-in-incognito-21796
Je ne pense pas que vous puissiez faire grand-chose pour changer cela, et Google a l'intention d'en faire le comportement par défaut à l'avenir: https://www.theverge.com/2020/1/14/21064698/google-third-party- cookies-chrome-deux-ans-confidentialité-safari-firefox
Cela est dû à un changement majeur dans la gestion des cookies pour aider à atténuer le CSRF. Suite à ce brouillon: https://tools.ietf.org/html/draft-west-first-party-cookies-07
Les solutions de contournement ci-dessus ne fonctionneront pas (la fonction setcookieSameSite) car vous devez définir le drapeau du même site sur l'identifiant de session (je peux voir que le PHPSESSID a également ce message, c'est-à-dire "Ce Set-Cookie a été bloqué en raison des préférences de l'utilisateur"). Ou peut-être en essayant le chemin session_set_cookie_params? (non testé).
En particulier pour la branche PHP 5.6 , vous devez définir l'attribut cookie de la session.
btw Il semble que le cookie qa_session dans votre capture d'écran soit un cookie aléatoire, pour celui-ci, vous pouvez utiliser la réponse @ Pierre-Pretorius, cela fonctionnera.
pour PHP 5.6.40, voir mon autre réponse ici: https://stackoverflow.com/a/64960472/1641763
@Jay Blanchard: J'ai spécifiquement dit qu'il ne s'agissait pas de modifier les paramètres de Chrome (ce qui est une réponse acceptée dans l'autre question). Et il ne traite pas de l'authentification unique, Ajax et PHP. - Soyez si gentil et retirez le drapeau de fermeture.
Avez-vous recherché tous les doublons et constaté qu'aucun ne vous concernait?
Bien sûr. Par exemple, stackoverflow.com /... ou google google.com/… ... Et encore une fois, juste pour souligner l'importance, tous les utilisateurs de SO / Stackexchange seront affectés.
Avez-vous déterminé que la cause est en fait le paramètre de l'utilisateur et vous souhaitez contourner ce paramètre. Ou que l'utilisateur les autorise, mais que vous recevez toujours ce message bloqué et que vous ne pouvez pas comprendre pourquoi il affiche le message bloqué alors que l'utilisateur n'a pas configuré pour bloquer les cookies?
J'ai les paramètres par défaut: Autoriser les sites à enregistrer et lire les données des cookies ON. Bloquer les tiers OFF . La connexion a fonctionné jusqu'à hier, maintenant elle s'est arrêtée avec l'avertissement ci-dessus. Essayez de vous connecter à SO, puis dirigez-vous vers superuser.com (ou un autre site sur lequel vous avez un deuxième compte). Vous n'êtes plus connecté.
Apparaît que les paramètres par défaut d'installation propre dans Chrome sont de bloquer les cookies tiers (tous). Ce qui peut être une montée en puissance pour leurs exigences SameSite dans une mise à jour de version ultérieure. Je suppose que c'est pour protéger les utilisateurs d'eux-mêmes, ce qui pose un problème lorsque Chrome décide que l'un de vos propres cookies est un cookie tiers (cookie défini à partir d'un domaine qui n'est pas le domaine actuel).
Cela ne devrait-il pas être demandé sur meta à la place?
Voici un enregistrement d'écran qui montre que la connexion SSO de Stackoverflow / Stackexchange / Superuser ne fonctionne plus: github.com/q2apro/gifs/blob/master / ...
@FunkFortyNiner Non, nous avons besoin d'une solution technique. De nombreux sites Web / développeurs rencontreront le même problème dans les prochains jours.
Cependant, vous oubliez que vous pouvez toujours vous connecter sur chaque site avec le même utilisateur. Ainsi, le blocage des cookies tiers n'affecte négativement que la `` facilité d'utilisation '' où vous êtes automatiquement connecté sur tous, lorsque vous vous connectez sur l'un d'eux. Les utilisateurs qui souhaitent cette facilité peuvent assouplir leurs paramètres de cookies par défaut. Cependant, cela ne les empêche pas de se connecter correctement sur chaque site.
Cela s'est-il produit dans Incognito? Chrome a un paramètre distinct pour bloquer les cookies tiers dans Incognito. J'ai été accroché à ce sujet pendant des heures aujourd'hui, puis lorsque j'ai utilisé une fenêtre standard (non-navigation privée), cela fonctionnait bien.
Cela se produit en mode standard et en mode incognito.