J'ai un problème avec un site Web où PHP ne permet pas de sauvegarder des variables de session pour des utilisateurs spécifiques avec Internet Explorer. Mais pour d'autres utilisateurs avec Internet Explorer, il n'y a aucun problème, et les utilisateurs avec d'autres navigateurs n'ont pas non plus de problèmes.
J'ai créé les trois petits scripts suivants pour vous assurer qu'aucun autre code sur le site Web n'a été impliqué:
test2.php: la sortie attendue pour le Cependant, la sortie pour le Les utilisateurs du problème sont les suivants: Cela signifie que les variables de session ne sont pas stockées pour ces utilisateurs. Cependant, l'ID de session pour les utilisateurs ayant des problèmes est le même pour les 3 pages de test. Quelqu'un a-t-il une idée de ce que cela pourrait être? Autant que je sache, le code problématique a travaillé depuis plusieurs années et que les problèmes ont commencé à montrer au cours du dernier mois. Modifier réponses aux questions Dans les commentaires: Comme indiqué par @ NL-X dans un commentaire, les données sont stockées dans la deuxième demande. J'ai donc adapté le scénario de test et ajouté une autre étape pour voir si les sessions fonctionnent dans des demandes suivantes. Et c'est le cas. Ensemble de données de session dans Alors, la question est de savoir pourquoi les données de session pour la première demande sont-elles perdues et non pour des demandes ultérieures? var_dump ($ _ session) serait quelque chose comme:
step2.php et step3.php sont enregistrés entre les demandes.
4 Réponses :
Je vais poser cela, au lieu d'attendre une personne ayant une connaissance spécifique du mécanisme de session de PHP:
Je travaille principalement avec ASP.NET, et la session à partir du manuel PHP ( http://www.php.net/manual /en/intro.session.php ):
Ceci est soit stocké dans un cookie du côté de l'utilisateur ou est propagé dans
l'URL.
utilise un cookie pour persister les données sur les demandes. Si PHP fonctionne de la même manière, la conclusion la plus évidente est que les utilisateurs possédant des problèmes de session ont des cookies désactivées ou utilisent des logiciels qui permettent uniquement aux domaines blanchissants de définir des cookies. Je verrai si je peux trouver des faits pour soutenir cette théorie ...
Je sais bien sûr pour au moins un utilisateur avec le problème qu'il a cookies activé.
@Tiesont. Oui, les cookies de PHP fonctionnent beaucoup comme vous l'avez décrit.
@ Jan-Henk chiffres. Cela aurait été beaucoup trop facile pour être le problème réel, non?
@ Jan-Henk cette réponse à une question similaire soulève des préoccupations?: Stackoverflow.com/a/306601/534109
@Tiesont. J'ai déjà trouvé ce peu d'informations moi-même, mais il n'y a pas - ou _ dans le nom de la machine. Mais merci quand même.
@ Jan-Henk une dernière pensée: Y a-t-il une excellente différence dans les fuseaux horaires des utilisateurs en question pour avoir une session "expirée"? J'ai lu un article ou deux qui indique que c'est-à-dire que c'est connu pour calculer de manière incorrecte les températures de temps locales plutôt que de faire correspondre d'abord le fuseau horaire du serveur ...
@Tiesont. Je demanderai à l'utilisateur de son fuseau horaire.
@Tiesont. La même idée est tombée dans ma tête. Mais le cookie de session n'est-il pas censé être un cookie de session :)? (Ce qui signifie que le cookie n'a aucune expiration, mais est jeté lorsque le navigateur s'en va.)
@ NL-X Pour être honnête, mes journées PHP sont derrière moi, mais ne ressemblent pas à ce qu'il faut être: php.net/manual/fr/...
À partir d'un phpinfo () appel i obtenez la valeur 0 pour session.cookie_lifetime .
@Tiesont. Ses paramètres de fuseau horaire de fuseau horaire sont les mêmes que le serveur.
Après avoir capturé les données réseau des utilisateurs avec des problèmes, j'ai compris que les utilisateurs ayant des problèmes avaient une image chromée installée. Avec ce peu d'informations, j'ai découvert ce que le problème était, je l'ai expliqué dans une réponse de la mienne. Mais merci de votre aide.
Je ne peux pas exactement vous dire pourquoi sur / après la première demande, le cookie semble se perdre. (C'est ce que je suppose que cela se passe.) Et pourquoi on / après la deuxième demande n'est pas perdue.
Peut-être en effet une question de mise en cache. Vérifiez les outils de développement et regardez ce qui se passe exactement dans l'onglet Réseau. La première demande est-elle à venir avec un 200 - OK, et la réponse contient-elle une en-tête de cookie? Ou est-ce vraiment mis en cache, comme l'un des commentaires suggéra? P>
mais à la fin, vous devriez réellement mettre en œuvre correctement ID de session qui passe (lisez-le). Ceci est destiné aux personnes qui ne veulent pas ou ne peuvent pas gérer les biscuits. P>
Cela signifie de fonder: p> dans: p> <a href="test3.php?<?php echo htmlspecialchars(SID); ?>">Next</a>
Je vais essayer de passer l'identifiant de la session dans le scénario de test et je vous ferai savoir le résultat dès que j'entends de l'utilisateur avec le problème. Mais si je me souviens bien que l'option --enable-trans-sid a été désactivée, car Google indexerait les mêmes pages plusieurs fois avec différentes valeurs phpsessid dans l'URL.
@ Jan-Henk qui est surprenant. Je suppose que les robots de cowler Google sont activés par le cookie. Et empêcherait ainsi PHP d'utiliser le SID dans les URL.
Ce changement a été fait il y a environ 5 ans, il pourrait donc être différent en ce moment. Mais nous n'avons jamais eu de problèmes de données de session tant que le mois dernier.
Le code a 5 ans, mais le problème a commencé le mois dernier? Cela vaut la peine de mentionner :) ... Avez-vous peut-être amélioré quelque chose (Apache, PHP, pare-feu, proxy)? Est-ce une question spécifique à la version? (Peut-être que seuls les utilisateurs avec le plus récent c'est-à-dire?)
Je l'ai mentionné dans l'OP :) J'ai demandé au fournisseur d'hébergement si quelque chose avait changé cela pourrait conduire à ces problèmes, mais ils ont dit non. En outre, ce ne sont que des utilisateurs avec IE, mais tous les utilisateurs avec IE. J'ai confirmé des rapports sur IE7 et IE9, mais parce que je ne peux pas reproduire le problème moi-même, je ne peux pas dire pour certains problèmes de ne pas avoir de problèmes avec d'autres versions d'IE.
Je demanderai à l'utilisateur de capturer les données réseau pour le scénario de test avec les outils de développeur F12. J'espère que je peux trouver quelque chose là-bas.
@ Jan-Henk Voir aussi mon édition. Peut-être même enregistrer $ _ serveur ['http_host'] dans votre fichier texte.
J'ai demandé à l'utilisateur de capturer les données réseau. Après cela, je vais regarder dans le domaine de la cookie. Mais si les demandes de l'utilisateur modifient la partie www, cela sera déjà visible à partir des données réseau capturées.
Après avoir capturé les données du réseau, j'ai compris que les utilisateurs ayant des problèmes avaient une image chromée installée. Avec ce peu d'informations, j'ai découvert ce que le problème était, je l'ai expliqué dans une réponse de la mienne. Mais merci de votre aide.
Tout d'abord, vous devriez vérifier votre configuration de session PHP.ini, en particulier la durée de la cookie. Ajouter une section à votre question. Installez Fiddler sur un client qui vous donne l'erreur et produit une dump HTTP complet de la session. Cela devrait vous aider à suivre facilement le problème.
La durée / la configuration de la cookie est déjà traitée dans les commentaires. IE Les outils de développeur F12 feront le faire. violeur n'est pas nécessaire.
Les informations pertinentes devraient être en question et non dans les commentaires. Au fait, je ne vois aucune section PHP.ini dans des commentaires. IE Les outils de développement ne peuvent pas enregistrer un journal de demande complète.
J'ai compris que les utilisateurs qui avaient les problèmes avaient tous eu un cadre chrome installé. J'ai vérifié cela en installant un cadre chromé sur une machine locale et, dans ce cas, j'ai pu reproduire les problèmes.
Les problèmes ont été causés par le fait que notre serveur a SUHOSIN installé. Les paramètres suivants de suhosine ont été activés: Cela signifie que la chaîne d'agent d'utilisateur fait également partie de l'identification d'une session d'utilisateur. Normalement, ce n'est pas un problème, mais pour les utilisateurs de la trame Chrome installée, la chaîne d'agent d'utilisateur diffère entre la première demande et les demandes suivantes. Après avoir désactivé ces réglages de suhosine, il n'y avait plus de problèmes.
Impressionnant. Ce n'est certainement pas quelque chose que j'ai envisagé, mais cela a du sens (bon de savoir, aussi bien). Bon travail.
@Gungfoo comment alors? IE9 + a un très bon soutien de normes.
@Hamzadzcyberdev environ 30% du monde, il semble: sitepoint.com/browser-Trends -March-2013
Les utilisateurs spécifiques ont-ils des cookies désactivés?
Ah au fait, avez-vous mis en œuvre "Cookie Wetguisving"? Peut-être que certains utilisateurs n'ont pas accepté vos cookies?
@Tiesont. Assez malheureusement ... :(
Nope ils n'ont pas de cookies désactivés. De Var_Dummp (Demande _ _), je peux également voir que les données PHPSESSID sont envoyées au serveur pour ces utilisateurs.
Il n'y a pas de code de mouillage de cookie dans les petits scripts de test que j'ai fournis à @hamzadzcyberdev.
En ignorant les trolls, à savoir un moment et de retourner à la question actuelle, pourriez-vous nous dire quelle version, à savoir la ou les versions que vous rencontrez des problèmes.
Ne pas traîner du tout, je l'ai testé sur IE8 et cela fonctionne comme prévu. Si nous ne pouvons pas reproduire l'erreur, il sera difficile de résoudre votre problème.
J'ai des rapports de problèmes d'utilisateurs avec IE7 et IE9. Mais je ne peux pas dire pour certitude qu'il n'y a pas de problèmes avec les autres versions, car cela pourrait être que ceux-ci ne sont tout simplement pas encore signalés. Et je ne peux pas reproduire le problème sur une machine locale.
@ Jan-Henk Un navigateur ne bloquera pas simplement un cookie de lui-même, il doit être configuré pour le faire. Si vous ne pouvez même pas reproduire l'erreur, ce serait presque impossible pour nous. Ce que je suggère, c'est de connecter les utilisateurs et de vérifier si Ils utilisent des cookies . Si vous pouviez demander à ceux qui ont signalé que le problème de coopérer serait mieux.
@Hamzadzcyberdev J'ai au moins un utilisateur avec le problème qui coopérera avec moi. Il n'a pas de cookies désactivé, aucun logiciel antivirus qui interfère et le problème existe pour lui dans les petits scripts de test que j'ai fournis.
Étrange ... je vais regarder de la ligne de touche pour l'instant ...
Pourquoi régénérerez-vous l'ID? (deuxième ligne de code)
@ NL-X empêchant la détournement de la session?
@ NL-X J'ai lu quelque part que la régénération de l'ID de session a résolu un problème similaire, alors j'ai essayé cela. Mais si la déclaration est dans le code ou non n'a aucune influence sur le résultat pour les utilisateurs ayant un problème. Mais je vais le modifier hors du code exemple, plus le témoignage est petit, mieux c'est.
Vous dites
Cela signifie que les variables de session ne sont pas stockées pour ces utilisateurs. Je suis en désaccord: la session n'est pas stockée sur la première demande, mais semble être stockée sur la deuxième demande. Comme sur la troisième demande, le comte est rappelé ...Cela semble être un problème de mise en cache sur les ordinateurs où les gens se sont plaints que les sessions ne fonctionnent pas. Malheureusement, il est hors de votre contrôle de résoudre ce problème et si vous ne pouvez pas reproduire le problème, le meilleur que vous puissiez faire est d'inspecter leur configuration, c'est-à-dire que ce soit derrière un proxy. Sans ces informations, vous ne pouvez pas créer de solution car tout fonctionne bien sur le côté PHP.
@ NL-X Vous avez raison que les données sont stockées sur la deuxième demande. Je vais ajouter une autre étape dans le scénario de test pour voir si les données de la troisième demande seront stockées ou non. Je reviendrai sur cela quand j'ai une réponse de l'utilisateur.
Iception fausse sur les cookies
Les cookies ne deviendront pas visibles avant le prochain chargement d'une page que le cookie doit être visible. Pour tester si un cookie a été défini avec succès, vérifiez le cookie sur une prochaine page de chargement avant l'expiration du cookie. L'expiration du temps est défini via le paramètre Expire. Une bonne façon de déboguer l'existence de cookies est simplement d'appeler simplement print_r ($ _ cookie); SOURCE . Donc, le comportement du premier test est attendu.@Hamzadzcyberdev OP dit également qu'il s'y attend de cette façon. Sa Sortie attendue commence par
array (0) {}@ NL-X J'ai édité l'OP, car comme vous l'avez dit, seules les données de session de la première demande sont perdues et non les données des demandes suivantes.