Les données de session PHP ne sont pas enregistrées

Question

J'ai l'un de ces & "Je jure de ne pas avoir touché le serveur &"; des situations. Honnêtement, je n'ai touché à aucun des scripts php. Le problème que je rencontre est que les données php ne sont pas enregistrées sur différentes pages ou que la page est actualisée. Je sais qu'une nouvelle session est créée correctement car je peux définir une variable de session (par exemple, $ _SESSION ['foo'] = & "Foo &"; Et l'imprimer correctement sur la même page. Mais Lorsque j'essaie d'utiliser cette même variable sur une autre page, elle n'est pas définie. Existe-t-il des fonctions php ou des informations que je peux utiliser sur mon serveur hôtes pour voir ce qui se passe?

Voici un exemple de script qui ne fonctionne pas actuellement sur le serveur de mes hôtes:

<?php
session_start();
if(isset($_SESSION['views']))
    $_SESSION['views'] = $_SESSION['views']+ 1;
else
    $_SESSION['views'] = 1;

echo "views = ". $_SESSION['views'];
echo '<p><a href="page1.php">Refresh</a></p>';
?>

La variable 'vues' n'est jamais incrémentée après un rafraîchissement de page. Je pense que c'est un problème de leur côté, mais je voulais d'abord m'assurer que je ne suis pas un idiot complet.

Voici le phpinfo () du serveur de mes hôtes (PHP Version 4.4.7):

Answer 1

Merci pour toutes les informations utiles. Il se trouve que mon hôte a changé de serveur et a commencé à utiliser un chemin de sauvegarde de session différent de / var / php_sessions qui n'existait plus. Une solution aurait été de déclarer ini_set(' session.save_path','SOME WRITABLE PATH'); dans tous mes fichiers de script, mais cela aurait été pénible. J'ai parlé avec l'hôte et ils ont explicitement défini le chemin de la session sur un chemin réel qui existait déjà. J'espère que cela aidera tous ceux qui ont des problèmes de chemin de session.

Answer 2

Assurez-vous de ne pas mélanger https: // avec http: //. Les variables de session ne circulent pas entre les sessions sécurisées et non sécurisées.

Answer 3

Avait le même problème - ce qui m'est arrivé, c'est que notre administrateur serveur a changé le booléen session.cookie_secure en On, ce qui signifie que les cookies ne seront envoyés que via une connexion sécurisée. Comme le cookie était introuvable, php créait une nouvelle session à chaque fois, ainsi les variables de session n'étaient pas visibles.

Answer 4

Utilisez phpinfo() et vérifiez les session.* paramètres.

Peut-être que les informations sont stockées dans des cookies et que votre navigateur n'accepte pas les cookies, quelque chose comme ça.

Vérifiez-le d'abord et revenez avec les résultats.

Vous pouvez également faire un & nbsp; print_r($_SESSION); pour faire un dump de cette variable et en voir le contenu ....

En ce qui concerne votre session.save_path, le <=> est-il valide? Votre serveur Web a-t-il un accès en écriture à ce répertoire?

J'espère que cela vous aidera.

Answer 5

J'ai eu le problème suivant

index.php

<?
    session_start();
    $_SESSION['a'] = 123;
    header('location:index2.php');
?>

index2.php

<?
  session_start();
  echo $_SESSION['a'];
?>

La variable $_SESSION['a'] n'a pas été définie correctement. Ensuite, j'ai changé le index.php suivant

<?
    session_start();
    $_SESSION['a'] = 123;
    session_write_close();
    header('location:index2.php');
?>

Je ne sais pas ce que cela signifie en interne, je viens de m'expliquer que le changement de variable de session n'était pas assez rapide:)

Answer 6

Vérifiez si le chemin de sauvegarde de la session est accessible en écriture par le serveur Web.

Assurez-vous que les cookies sont activés .. (je les oublie lorsque je les éteins pour tester quelque chose)

Utilisez firefox avec l'extension firebug pour voir si le cookie est en train d'être créé et retransmis.

Et sur une note indépendante, commencez à regarder php5, car php 4.4.9 est le dernier de la série php4.

Answer 7

Vérifiez qui sont le groupe et le propriétaire du dossier dans lequel le script est exécuté. Si l'ID de groupe ou l'ID utilisateur est incorrect, par exemple, défini sur root, les sessions ne seront pas enregistrées correctement.

Answer 8

Vérifiez la valeur de " views " quand avant de l'incrémenter. Si, pour une raison quelconque, la chaîne est définie, alors si vous ajoutez 1, elle renvoie toujours 1.

if (isset($_SESSION['views'])) {
    if (!is_numeric($_SESSION['views'])) {
        echo "CRAP!";
    }
    ++$_SESSION['views'];
} else {
    $_SESSION['views'] = 1;
}

Answer 9

Eh bien, nous pouvons éliminer les erreurs de code car j'ai testé le code sur mon propre serveur (PHP 5).

Voici ce qu'il faut vérifier:

1. Appelez-vous session_unset () ou session_destroy () n'importe où? Ces fonctions effaceront immédiatement les données de la session. Si je les mets à la fin de mon script, il commence à se comporter exactement comme vous le décrivez.

2. agit-il de la même manière dans tous les navigateurs? Si cela fonctionne sur un navigateur et pas sur un autre, vous pouvez avoir un problème de configuration sur le navigateur qui ne fonctionne pas (c'est-à-dire que vous avez désactivé les cookies et oublié de les activer, ou que vous bloquez les cookies par erreur).

3. Le dossier de session est-il accessible en écriture? Vous ne pouvez pas tester cela avec is_writable (), vous devrez donc aller dans le dossier (à partir de phpinfo (), cela ressemble à / var / php_sessions) et vous assurer que les sessions sont bien en cours de création.

Answer 10

Si vous définissez une session en php5, essayez de la lire sur une page php4, il se peut qu'elle ne soit pas au bon endroit! Faites en sorte que les pages aient la même version php ou définissez le chemin session_path.

Answer 11

J'ai passé des années à chercher la solution à un problème similaire. Ce n'était pas un problème avec le code ou la configuration, car un code très similaire fonctionnait parfaitement dans un autre fichier .php sur le même serveur. Il s’est avéré que le problème était dû à une très grande quantité de données sauvegardées dans la session sur cette page. À un endroit, nous avions une ligne comme celle-ci: $_SESSION['full_list'] = $full_list où $full_list était un tableau de données chargé à partir de la base de données; chaque ligne était un tableau d'environ 150 éléments. Lorsque le code a été écrit pour la première fois il y a quelques années, la base de données ne contenait qu'environ 1 000 lignes. Par conséquent, <=> contenait environ 100 éléments, chacun représentant un tableau d'environ 20 éléments. Avec le temps, les 20 éléments transformés en 150 et 1000 lignes ont été transformés en 17000, de sorte que le code stockait près de 64 Mo de données dans la session. Apparemment, avec cette quantité de données stockées, il refusait de stocker quoi que ce soit d'autre. Une fois que nous avons modifié le code pour traiter les données localement sans les enregistrer dans la session, tout a parfaitement fonctionné.

Answer 12

  

Je connais une solution que j'ai trouvée (OSX avec Apache 1 et venant de passer à PHP5) alors que je rencontrais un problème similaire: la non-définition d'une clé spécifique (c'est-à-dire non définie ($ _SESSION ['clé']);) ne le causait pas sauver. Dès que je n'ai plus retiré cette clé, elle a été sauvegardée. Je ne l'ai jamais revu, sauf sur ce serveur situé sur un autre site, mais c'était une variable différente. Rien de spécial non plus.

Merci pour celui-ci Darryl. Cela m'a aidé. J'étais en train de supprimer une variable de session et, pour une raison quelconque, cela empêchait la session de s'engager. maintenant, je mets simplement la valeur null à la place (ce qui convient à mon application), et cela fonctionne.

Answer 13

Je connais une solution que j'ai trouvée (OSX avec Apache 1 et venant de passer à PHP5) alors que je rencontrais un problème similaire: la non-définition d'une clé spécifique (c'est-à-dire non définie ($ _SESSION ['clé']);) ne le causait pas sauver. Dès que je n'ai plus retiré cette clé, elle a été sauvegardée. Je ne l'ai jamais revu, sauf sur ce serveur situé sur un autre site, mais c'était une variable différente. Rien de spécial non plus.

Answer 14

Voici un problème courant que je n’ai pas vu résoudre dans les autres commentaires: votre hôte utilise-t-il un cache quelconque? S'ils mettent automatiquement en cache les résultats, vous obtiendrez ce genre de comportement.

Answer 15

Je voulais juste ajouter une note indiquant que cela peut également se produire si vous manquez accidentellement l'instruction session_start () sur vos pages.

Answer 16

Le chemin du cookie de session était défini sur " // " au lieu de " / " ;. Firebug est génial. J'espère que ça aidera quelqu'un.

Answer 17

J'ai eu ce problème lorsque j'utilisais des pages sécurisées provenant de www.domain.com/auth.php et redirigées vers domain.com/destpage.php. J'ai enlevé le www du lien auth.php et cela a fonctionné. Cela m'a jeté parce que tout a fonctionné autrement; la session n'était pas encore définie quand je suis arrivé à destination.

Answer 18

Un problème commun souvent négligé est également qu'il ne doit y avoir AUCUN autre code ou espacement supplémentaire avant la commande session_start ().

J'ai déjà eu ce problème auparavant avec une ligne vide avant session_start (), ce qui l'empêchait de fonctionner correctement.

Answer 19

Ajout de ma solution:

Vérifiez si vous accédez au domaine correct . J'utilisais www.mysite.com pour démarrer la session et j'essayais de la recevoir de mysite.com (sans le www).

J'ai résolu ce problème en ajoutant une réécriture htaccess de tous les domaines sur www afin d'être sûr / du site.

Vérifiez également si vous utilisez http ou https.

Answer 20

Modifiez votre php.ini.
Je pense que la valeur de session.gc_probability est 1, alors réglez-le sur 0.

session.gc_probability=0

Answer 21

Vérifiez si vous utilisez session_write_close (); n'importe où, je l'utilisais juste après une autre session, puis j'essayais d'écrire à nouveau sur la session et cela ne fonctionnait pas .. alors commentez simplement que sh * t out

Answer 22

Encore quelques choses que je devais faire (j'avais le même problème: pas de rétention de session après la mise à niveau de PHP vers la version 5.4). Vous n’en aurez peut-être pas besoin, selon le contenu du fichier php.ini de votre serveur (vérifiez phpinfio ());

session.use_trans_sid=0 ; Do not add session id to URI (osc does this)
session.use_cookies=0;  ; ensure cookies are not used
session.use_only_cookies=0 ; ensure sessions are OK to use IMPORTANT
session.save_path=~/tmp/osc; ; Set to same as admin setting
session.auto_start = off; Tell PHP not to start sessions, osc code will do this

Fondamentalement, votre fichier php.ini devrait être défini sur aucun cookie et les paramètres de session doivent être cohérents avec ce que veut osc.

Il se peut que vous deviez également modifier quelques extraits de code de session dans application_top.php - créer des objets qui n'existent pas dans les appels tep_session_is_registered (...) (par exemple, un objet de navigation), définissez $ HTTP_ variables sur le plus récent $ _SERVER. uns et quelques autres tests isset pour les objets vides (google pour info). J'ai fini par être capable d'utiliser les fichiers originaux de sessions.php (includes / classes et includes / functions) avec un fichier application_top.php légèrement modifié pour que les choses se reprennent. Le problème principal était les paramètres php.ini, mais cela dépend bien sûr de ce que votre compagnie de serveur a installé par défaut.