Données de session perdues dans Chrome uniquement
J'ai un problème similaire, voire identique, à celui de ce fil de discussion: Perte aléatoire des variables de session uniquement dans Google Chrome et la réécriture d'URL
Mais toutes les solutions de ce fil ne fonctionnent pas pour moi. J'obtiens un comportement étrange de Google Chrome uniquement dans mon application PHP/MySQL. Si je l'essaie avec Firefox, cela fonctionne, mais pas Chrome.
Je navigue vers un endroit de mon panier et à plusieurs endroits du code où je stocke les données de session. Ne vous inquiétez pas si je commence la session ou quoi que ce soit en rapport avec ça, j'ai 11 ans dans le développement d'applications web, tout se passe bien.
Dans tous les navigateurs, je peux var_dump($_SESSION) et récupérer mes données, mais dans Chrome, les données ne sont pas conservées. Notez également que la session est transmise, je peux consulter le moniteur réseau et voir le cookie envoyé et de nombreux autres éléments liés au travail de session, mais le $_SESSION['last_viewed_element'] n’est pas conservé. Je ne peux pas non plus sembler régler autre chose, tout est perdu.
MODIFIER:
Problème résolu en passant de SESSIONS à COOKIES ...
J'ai eu un problème très similaire, dans mon cas, le problème était un 404 appelé en raison d'un favicon.ico manquant dans Chrome uniquement. Le 404.php a appelé le pied de page qui a modifié les variables Session . J'espère que cela aidera quelqu'un.
Le problème pourrait être que votre serveur recherche des favicons. S'il ne le trouve pas, il envoie une redirection 302, qui tue les variables de session.
J'ai eu ce problème et j'ai pu le résoudre. Chrome continue de rechercher un fichier .ico qui, pour une raison quelconque, l’affectait. Une fois que j'ai placé le fichier .ico à la racine du site, tout a commencé à fonctionner. Fou mais vrai.
J'ai rencontré le même problème, mais sous IIS avec ASP.Net MVC. IE et Firefox se débrouillaient bien, mais sous Chrome, je perdais des données de session. Finalement, nous avons découvert qu'une erreur 404 effaçait un cookie dans Chrome. Voici les étapes que j'ai suivies pour trouver le problème et le résoudre. Je suggère aux autres d'essayer:
Sous Chrome, utilisez Outils -> Outils de développement. Actualisez la page pour que "Outils de développement" commence à afficher les données.
Sur les outils de développement, Vérifier les ressources -> Cookies. Juste après une connexion réussie, j'avais 2 cookies pour le domaine que je testais. Lors de la navigation vers la page où j'ai perdu la session, l'un des cookies ne s'est plus présenté. La capture d'écran a été prise après le correctif, affichant les deux cookies:
![enter image description here]()
Maintenant, vérifiez l'onglet Réseau. Recherchez attentivement toute ressource (html/image/css/js/...) qui contient une erreur. J'ai eu une erreur 404 pour un fichier de police. L'erreur 404 a été provoquée par l'absence du type mime dans IIS . La résolution de l'erreur 404 a effacé le problème dans Chrome. La capture d'écran, à nouveau prise après correction, contenait toutes les ressources dont l'état était OK:
![enter image description here]()
En bonus, le fait d’enquêter sur ce problème m’a aidé à découvrir le type de mime manquant dans IIS, qui affectait davantage de pages sur tous les navigateurs.
Essayez ceci avant de perdre votre temps
Si vous êtes déjà connecté à votre espace Web (Panneau de configuration/Cpanel/Plesk Panel) dans le même navigateur. Puis déconnectez-vous de ce panneau de contrôle et effacez le cookies et essayez à nouveau
En cas de
données de session perdues en chrome uniquement
Dans mon cas, je viens de réinitialiser le navigateur chrome}
Allez sur chrome: // paramètres/puis cliquez sur avancé puis réinitialiser
Avait le même problème et finalement résolu. La session de connexion avec domain.com était dans la redirection, mais c'était www.domain.com. IE et FF semblent supposer que www et aucun www sont identiques mais Chrome non. Trouvé en vérifiant l'hôte dans le journal réseau pour chaque chargement de page.
En regardant sur le lien suivant: http://code.google.com/p/chromium/issues/detail?id=45582
Je pense que le problème est que PHP reçoive la demande qui ne correspond pas à un fichier, puis ne gère pas correctement les fichiers 404. Je devais dire à Nginx de faire correspondre n'importe quelle URL avec favicon.ico, puis de renvoyer un 404.
Voici ma ligne pour Nginx:
if ($request_uri ~ 'favicon') {
return 404;
}
Le code avec lequel je travaillais avait le même problème. Résolu en supprimant les éléments suivants:
session_id($_GET['sid']);
session_write_close();
HA! je l'ai finalement résolu!
Lorsque vous effectuez une redirection header() en PHP, vous devez effectuer une die() juste après. Cela ne le résout que pour tous les navigateurs, à l'exception de Chrome.
Pour Chrome, vous devez également effectuer une session_write_close() juste avant la header().
Succès Sweeeeeeeeet
J'ai résolu le problème en supprimant la ligne:
base href="http://mysite/"
de la balise head dans le code HTML.
J'ai eu le même problème, j'ai découvert la raison qui était très étrange. Dans mon cas, une URL d’image dans une classe CSS était fausse !! Le navigateur ne peut pas charger l'image et, comme la page était un formulaire d'inscription avec un mot de passe, le navigateur a réinitialisé la session pour des raisons de sécurité.
J'ai trouvé que ma version du problème était exactement telle que décrite ici et ici et je souhaite donc ajouter un qualificatif supplémentaire à ce qui précède:
Google Chrome (v.59, stable) L'inspecteur ne vous indique pas que le fichier favicon.ico est inaccessible et ne vous indique pas que la page est redirigée 302.
Nous avons eu le même problème hier toute la journée.
Ce qui (apparemment) l'a résolu (pour nous) était une mise à jour Chrome.
Nous avions la version 45.0.2454.93 et depuis la mise à jour vers la version 45.0.2454.99 le problème ne se reproduisait plus ...
Je ne suis pas sûr si votre cas est similaire au mien. Mais pour moi la raison était la formation de l'URL.
Avec chrome, lors de la saisie de l'URL sous la forme " http://www.domainname.com " et de la définition des variables de session à cet emplacement.
et rediriger avec " http://domainname.com " sans le WWW. le sessionid n'est pas réutilisé.
Cela a résolu mon problème, espérons que c'est de l'aide
Vous perdez probablement des sessions uniquement sur votre environnement de développement, ce qui est probablement dû à la "même stratégie d'origine" de Chrome. Si tel est le cas, voici votre solution Désactivez la même stratégie d'origine dans Chrome
Dans votre fichier inp php essayez le réglage
session.save_path = /path/to/your/tmp
Sur certains serveurs, parfois, la session a besoin d’un fichier de session explicitement direct pour être sauvegardée dans un répertoire local.
Cela a résolu mon problème instantanément: allez dans chrome://settings/cookies puis localisez votre hôte local puis supprimez ses cookies. La solution est si simple, ça vaut le coup d'essayer