Session PHP perdue après la redirection


132

Comment résoudre le problème de la perte d'une session après une redirection en PHP?

Récemment, j'ai rencontré un problème très courant de perte de session après redirection. Et après avoir cherché sur ce site Web, je ne trouve toujours aucune solution (bien que ce soit le plus proche).

Mettre à jour

J'ai trouvé la réponse et j'ai pensé la publier ici pour aider toute personne rencontrant le même problème.


1
La question est de savoir comment résoudre le problème de la perte d'une session après une redirection en PHP. J'ai déjà trouvé la réponse en la publiant ici pour que les autres le sachent. Parce que ma solution n'est pas sur StackOverflow.
dayuloli

2
C'est bien, mais c'est un site de contrôle qualité. Veuillez faire de votre question une question.
jeremy

Je n'ai pas remarqué que c'était de toi. Pourtant, ce site est pour les questions, pas pour les réponses aux questions que vous connaissez déjà.
Aris


21
@Aris Ce n'est pas vrai, lorsque les gens ont une question sur le codage, ils se tournent vers StackOverflow pour obtenir de l'aide. S'il n'y a pas de réponses disponibles, ils ne peuvent pas obtenir l'aide dont ils ont besoin. J'essaie de fournir cette réponse.
dayuloli

Réponses:


209

Effectuez d'abord ces vérifications habituelles:

  1. Assurez-vous que session_start();est appelé avant que des sessions soient appelées. Donc, une valeur sûre serait de le mettre au début de votre page, immédiatement après la <?phpdéclaration d' ouverture avant toute autre chose. Assurez-vous également qu'il n'y a pas d'espaces / tabulations avant la <?phpdéclaration d' ouverture .
  2. Après la headerredirection, terminez le script actuel en utilisant exit();(D'autres ont également suggéré session_write_close();et session_regenerate_id(true), vous pouvez également les essayer, mais j'utiliserais exit();)
  3. Assurez-vous que les cookies sont activés dans le navigateur que vous utilisez pour le tester.
  4. Assurez register_globals- vous qu'il est désactivé, vous pouvez le vérifier sur le php.inifichier et également en utilisant phpinfo(). Reportez-vous à ceci pour savoir comment le désactiver.
  5. Assurez-vous que vous n'avez pas supprimé ou vidé la session
  6. Assurez-vous que la clé de votre $_SESSIONtableau super global n'est écrasée nulle part
  7. Assurez-vous de rediriger vers le même domaine. Donc, la redirection d'un www.yourdomain.comvers yourdomain.comne fait pas avancer la session.
  8. Assurez-vous que votre extension de fichier est .php(cela arrive!)

Maintenant, ce sont les erreurs les plus courantes, mais si elles ne font pas l'affaire, le problème est probablement lié à votre société d'hébergement. Si tout fonctionne sur localhostmais pas sur votre serveur distant / de test, c'est probablement le coupable. Vérifiez donc la base de connaissances de votre fournisseur d'hébergement (essayez également leurs forums, etc.). Pour les entreprises comme FatCow et iPage, elles vous demandent de le préciser session_save_path. Alors comme ça:

session_save_path('"your home directory path"/cgi-bin/tmp');
session_start();

(remplacez "votre chemin de répertoire personnel" par le chemin d'accès réel de votre répertoire personnel. Il se trouve généralement dans votre panneau de contrôle (ou équivalent), mais vous pouvez également créer un test.phpfichier sur votre répertoire racine et saisir:

<?php echo $_SERVER['SCRIPT_FILENAME']; ?>

Le bit avant «test.php» est le chemin de votre répertoire personnel. Et bien sûr, assurez-vous que le dossier existe réellement dans votre répertoire racine. (Certains programmes ne téléchargent pas de dossiers vides lors de la synchronisation)


8
Très bien écrit +1, si tout échoue, utilisez simplement des cookies (générez une chaîne de manière aléatoire et stockez-la dans la base de données et utilisez-la comme valeur de cookie).
Dave Chen

2
basculer entre http et https peut également être un problème stackoverflow.com/questions/441496/…
dev.e.loper

4
Notez qu'à partir de php 5.4.0 register_globals a été supprimé, donc cela ne posera plus de problème
anthonygore

2
Vérifiez également le journal des erreurs du serveur Web; dans mon cas, il y avait une erreur "Impossible d'écrire les données de session (fichiers). Veuillez vérifier que le paramètre actuel de session.save_path est correct". Les autorisations étaient incorrectes sur le répertoire save_path.
timbonicus

Une raison pour laquelle mes sessions seraient stockées ailleurs que dans session.save_path?
Justin le

26

vous devriez utiliser "exit" après l'appel d'en-tête

header('Location: http://www.example.com/?blabla=blubb');
exit;

Il y a un bogue pour Gecko (par exemple Waterfox, Firefox, SeaMonkey) où s'il y a une sortie de données (par exemple echo ' ';) ou des espaces de quelque sorte que ce soit, il ignorera complètement l'en-tête de l'emplacement.
John

18

J'ai essayé toutes les solutions possibles, mais aucune n'a fonctionné pour moi! Bien sûr, j'utilise un service d'hébergement partagé.

En fin de compte, j'ai contourné le problème en utilisant 'url relative' dans l'en-tête de redirection!

header("location: http://example.com/index.php")

annulé les cookies de session

header("location: index.php")

a fonctionné comme un charme!


7

J'ai eu le même problème. J'ai travaillé dessus pendant plusieurs heures et cela m'a rendu fou.

Dans mon cas, le problème était un 404 appelé en raison d' un favicon.ico manquant dans Chrome et Firefox uniquement. Les autres navigateurs ont bien fonctionné.


Je voulais juste vous remercier pour cette réponse, m'a fait réaliser que 404 demandes d'images étaient transmises par Varnish à PHP sans aucun cookie et que de nouvelles sessions étaient donc constamment créées. Peut-être ne l’aurait jamais compris sans vous
Pascal Zajac

J'ai eu le même problème, mon favicon.ico était en cours de redirection (redirection 302 du sous-domaine vers le domaine principal) et ainsi généré une nouvelle session à chaque fois. Merci beaucoup!
simdrouin

4

Quand j'utilise le chemin relatif "dir / file.php" avec la fonction header () fonctionne pour moi. Je pense que la session n'est pas enregistrée pour une raison quelconque lorsque vous redirigez en utilisant l'url complète ...

//Does retain the session info for some reason
header("Location: dir");

//Does not retain the session for some reason
header("Location: https://mywebz.com/dir")

3

Cela m'a déconcerté pendant longtemps (et cet article était super à trouver!) Mais pour tous ceux qui ne peuvent toujours pas faire fonctionner les sessions entre les redirections de page ... j'ai dû aller dans le fichier php.ini et activer les cookies :

session.use_cookies = 1 

Je pensais que les sessions fonctionnaient sans cookies ... en fait, je sais qu'elles DEVRAIENT ... mais cela a résolu mon problème au moins jusqu'à ce que je puisse comprendre ce qui peut se passer dans une vue d'ensemble.


Je ne savais pas que les sessions pouvaient fonctionner sans cookies! Apprenez quelque chose de nouveau tous les jours! programmerinterview.com/index.php/php-questions/…
dayuloli

bien sûr, ils PEUVENT fonctionner sans cookies dépend de votre configuration. Mais vous devez savoir ce que vous faites. Et ayez une bonne raison de le faire. Parce que c'est moins sûr. et au cas où vous devriez travailler pour une raison quelconque sans cookies. Vous devez au moins configurer ini_set ('session.use_strict_mode', '1'); et ont généralement un temps de session court et après la connexion de l'utilisateur, utilisez session_regenerate_id (). Mais soyez averti si un utilisateur publie un lien vers un site sur votre serveur dans un forum, les personnes qui cliquent réellement sur ce lien reprendront la session. Peut-être que vérifier l'adresse IP est également une bonne idée.
Michael

3

J'ai eu un problème similaire, même si mon contexte était légèrement différent. J'avais une configuration de développement local sur une machine dont le nom d'hôte windowset l'adresse IP étaient 192.168.56.2.

Je pourrais accéder au système en utilisant l'un des éléments suivants:

Après la connexion, mon code PHP serait redirigé en utilisant:

header('http://windows/');

Si le nom de domaine précédent utilisé pour accéder au système ne l'était pas windows, les données de session seraient perdues. J'ai résolu cela en changeant le code en:

header('http://'.$_SERVER['HTTP_HOST'].'/');

Il fonctionne désormais quel que soit le nom de domaine local ou l'adresse IP que l'utilisateur insère.

J'espère que cela pourra être utile à quelqu'un.


3

J'ai rencontré ce problème sur une page particulière. Je définissais les valeurs $ _SESSION dans d'autres pages juste avant la redirection et tout fonctionnait bien. Mais cette page particulière ne fonctionnait pas.

Finalement j'ai réalisé que dans cette page particulière, je détruisais la session au début de la page mais je ne la relançais jamais. Donc, ma fonction de destruction a changé de:

function sessionKill(){

    session_destroy();

}

à:

function sessionKill(){

    session_destroy();
    session_start();

}

Et tout a fonctionné!


3

J'avais le même problème. Tout à coup, CERTAINES de mes variables de session ne persisteraient pas à la page suivante. Le problème s'est avéré être (en php7.1) que l'emplacement de l'en-tête ne doit pas contenir de WWW, ex https: // mysite . est ok, https: //www.mysite . perdra ces variables de session de pages. Pas tout, juste cette page.


C'est parce qu'il www.mysite.comest considéré comme un domaine complètement différent de blog.mysite.comou simplementmysite.com
dayuloli

2

Je me débat avec cela depuis des jours, vérifiant / essayant toutes les solutions, mais mon problème était que je n'ai pas rappelé session_start();après la redirection. J'ai juste supposé que la session était «toujours vivante».

Alors n'oublie pas ça!


Oui! c'était aussi mon problème. Je pensais que démarrer une session PHP était comme allumer une lumière pour toute la maison. Je n'avais pas réalisé que vous deviez tourner l'interrupteur pour chaque pièce dans laquelle vous entrez.
Dale Thompson

1

J'ai eu le même problème et j'ai trouvé le moyen le plus simple. J'ai simplement redirigé vers une redirection .html avec 1 ligne de JS

<!DOCTYPE html>
<html>
<script type="text/javascript">
<!--
window.location = "admin_index.php";
//–>
</script>
</html>

au lieu de PHP

header_remove();
header('Location: admin_login.php');
die;

J'espère que ça aide.

Amour Gram


1

Si vous utilisez, session_set_cookie_params()vous voudrez peut-être vérifier si vous passez le quatrième paramètre $securecomme true. Si c'est le cas, vous devez accéder à l'URL en utilisant https.

Le $secureparamètre étant vrai signifie que la session n'est disponible que dans une demande sécurisée. Cela peut vous affecter localement plus que dans les environnements de scène ou de production.

Le mentionner parce que je viens de passer la majeure partie de la journée à essayer de trouver ce problème, et c'est ce qui l'a résolu pour moi. Je viens d'être ajouté à ce projet et personne n'a mentionné qu'il nécessitait https.

Vous pouvez donc soit utiliser https localement, soit définir le paramètre $securesur FALSEpuis utiliser http localement. Assurez-vous simplement de le redéfinir sur vrai lorsque vous augmentez vos modifications.

En fonction de votre serveur local, vous pourriez avoir à modifier DocumentRootdans le httpd-ssl.confdu serveur afin que votre URL local est servi https.


1

Une autre raison possible:

C'est l'espace de stockage de mon serveur. L'espace disque de mon serveur est saturé. Ainsi, j'ai supprimé quelques fichiers et dossiers de mon serveur et essayé.

Cela a fonctionné !!!

J'enregistre ma session dans AWS Dynamo DB, mais il attend toujours de l'espace sur mon serveur pour traiter la session. Pas certain de pourquoi!!!


1

Si vous utilisez Laravel et que vous rencontrez ce problème, vous devez enregistrer vos données de session avant de rediriger.

session()->save();
// Redirect the user to the authorization URL.
header('Location: ' . $authorizationUrl);
exit;

0

J'ai également eu le même problème avec la redirection ne fonctionnant pas et j'ai essayé toutes les solutions que je pouvais trouver, ma redirection d'en-tête était utilisée dans un formulaire.

Je l'ai résolu en mettant la redirection d'en-tête dans une page php différente 'signin_action.php' et en passant les paramètres de variables que je voulais dans les paramètres d'url, puis en les réaffectant sous la forme 'signin_action.php'.

signin.php

if($stmt->num_rows>0) {
$_SESSION['username'] = $_POST['username'];
echo '<script>window.location.href = "http://'.$root.'/includes/functions/signin_action.php?username='.$_SESSION['username'].'";</script>';
error_reporting(E_ALL);

signin_action.php

<?php
require('../../config/init.php');
$_SESSION['username'] = $_GET['username'];
if ($_SESSION['username']) {

echo '<script>window.location.href = "http://'.$root.'/user/index.php";</script>';
exit();
} else {
echo 'Session not set';
}

?>

Ce n'est pas une belle solution, mais cela a fonctionné.


0

Pour moi, l'erreur est que j'ai essayé de sauvegarder un objet non sérialisable dans la session afin qu'une exception soit levée lors de la tentative d'écriture de la session. Mais comme tout mon code de gestion des erreurs avait déjà cessé toute opération, je n'ai jamais vu l'erreur.

Je pourrais le trouver dans les journaux d'erreurs Apache, cependant.


0

Juste pour mémoire ... J'ai eu ce problème et après quelques heures à tout essayer, le problème était que le disque était plein et que les sessions php ne pouvaient pas être écrites dans le répertoire tmp ... donc si vous rencontrez ce problème, vérifiez que aussi...


Cette réponse a fonctionné pour moi. Nous exécutons une Amazon Machine Image avec nginx. Il semble y avoir un problème si le dossier de session n'est pas la propriété du bon utilisateur (dans notre cas www), donc l'exécution chown -R www.wwwsur le dossier de sessions résout le problème.
Joshua

0

Pour moi, Firefox a stocké l'identifiant de session (PHPSESSID) dans un cookie, mais Google Chrome a utilisé le paramètre GET ou POST. Il vous suffit donc de vous assurer que le script de retour (pour moi: paiement paypal) valide PHPSESSID dans l'url ou le paramètre POST.


0

Après avoir essayé de nombreuses solutions ici sur SO et d'autres blogs ... ce qui a fonctionné pour moi a été d'ajouter .htaccess à la racine de mon site Web.

RewriteEngine on
RewriteCond %{HTTP_HOST} ^yoursitename.com$
RewriteRule ^.*$ "http\:\/\/www\.yoursitename\.com" [R=301,L]

0

Si vous utilisez Wordpress, j'ai dû ajouter ce hook et démarrer la session sur init:

function register_my_session() {
    if (!session_id()) {
        session_start();
    }
}
add_action('init', 'register_my_session');

0

Rien n'a fonctionné pour moi mais j'ai trouvé ce qui a causé le problème (et je l'ai résolu):

Vérifiez les cookies de votre navigateur et assurez-vous qu'il n'y a pas de cookies de session php sur différents sous-domaines (comme un pour " www.website.com " et un pour " website.com ").

Cela était dû à un javascript qui utilisait incorrectement le sous-domaine pour définir des cookies et ouvrir des pages dans des iframes.


0

Tout d'abord, assurez-vous que vous appelez session_start()avant d'utiliser $_SESSIONvariable.

Si vous avez désactivé le rapport d'erreurs, essayez de l'activer et de voir le résultat.

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

Les raisons les plus courantes qui ne sont pas mentionnées dans la réponse de @ dayuloli:

  1. Problème d'espace disque. Assurez-vous que votre espace disque n'est pas plein, vous avez besoin d'espace pour stocker les fichiers de session.

  2. Le répertoire de session peut ne pas être accessible en écriture. Vous pouvez le vérifier avecis_writable(session_save_path())


0

J'avais le même problème et je suis devenu fou de recherche dans mon code pour la réponse. Enfin, j'ai trouvé que mon hébergement a récemment mis à jour la version PHP sur mon serveur et n'a pas correctement configuré le session_save_pathparamètre sur le php.inifichier.

Donc, si quelqu'un lit ceci, veuillez vérifier la php.iniconfiguration avant toute autre chose.


0

Assurez-vous que session_write_closen'est pas appelé entre session_start()et lorsque vous définissez votre session.

session_start();

[...]

session_write_close();

[...]

$_SESSION['name']='Bob'; //<-- won't save

0

Maintenant que le RGPD est une chose, les personnes qui consultent cette question utilisent probablement un script de cookie. Eh bien, ce script a causé le problème pour moi. Apparemment, PHP utilise un cookie appeléPHPSESSID pour suivre la session. Si ce script le supprime, vous perdez vos données.

J'ai utilisé ce script de cookie . Il a une option pour activer les cookies «essentiels». J'ai ajouté PHPSESSIDà la liste, le script a arrêté de supprimer le cookie et tout a recommencé à fonctionner.

Vous pourriez sans doute permettre à un certain paramètre PHP pour éviter d' utiliser PHPSESSID, mais si votre script cookie est la cause du problème, pourquoi ne pas fixer que .


0

J'ai résolu ce problème après plusieurs jours de débogage et c'était tout parce que mon URL de retour provenant de PayPal Express Checkout n'avait pas de «www». Chrome a reconnu que les domaines devaient être traités de la même manière, mais d'autres navigateurs ne le faisaient parfois pas. Lorsque vous utilisez des sessions / cookies et des chemins absolus, n'oubliez pas le 'www'!


0

J'ai corrigé en accordant des autorisations d'écriture au groupe sur le chemin où PHP stockait les fichiers de session. Vous pouvez trouver le chemin de session avec la fonction session_save_path ().


0

Aujourd'hui j'ai eu ce problème dans un projet et j'ai dû changer ce paramètre en false (ou supprimer les lignes, par défaut est désactivé):

ini_set( 'session.cookie_secure', 1 );

Cela s'est produit parce que le projet réel fonctionne sur http et pas uniquement sur https. Vous avez trouvé plus d'informations dans la documentation http://php.net/manual/en/session.security.ini.php


0
ini_set('session.save_path',realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session'));
session_start();

Trop tard pour répondre mais cela a fonctionné pour moi


0

Pour moi, c'était une erreur d'autorisation et cela l'a résolu:

chown -R nginx: nginx / var / opt / remi / php73 / lib / php / session

J'ai testé quelques heures sur PHP et le dernier test que j'ai fait est que j'ai créé deux fichiers session1.php et session2.php.

session1.php:

session_start();

$_SESSION["user"] = 123;

header("Location: session2.php");

session2.php:

session_start();

print_r($_SESSION);

et il imprimait un tableau vide.

À ce stade, je pensais que cela pouvait être un problème de serveur et en fait, c'était le cas.

J'espère que cela aide quelqu'un.


1
Le chown est une mauvaise solution, car il sera rétabli à la valeur par défaut lors de la mise à jour du package. Voir les commentaires dans la configuration du pool par défaut (www.conf). Bonne façon si vous utilisez un autre répertoire que celui d'Apache (ex: / var / lib / php / nginx / session)
Remi Collet

Vous avez raison. la mise à jour du package était la raison de mon problème en premier lieu. Mais puisque c'est ainsi que cela a été fait et que j'avais besoin d'une solution rapide, cela m'a aidé. Mon administrateur SYS l'a résolu, je ne suis pas proche de Linux.
temo
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.