Sessione PHP persa dopo il reindirizzamento


132

Come posso risolvere il problema di perdere una sessione dopo un reindirizzamento in PHP?

Di recente, ho riscontrato un problema molto comune di perdere la sessione dopo il reindirizzamento. E dopo aver cercato su questo sito non riesco ancora a trovare una soluzione (anche se questo è arrivato il più vicino).

Aggiornare

Ho trovato la risposta e ho pensato di pubblicarla qui per aiutare chiunque abbia lo stesso problema.


1
La domanda è come risolvere il problema di perdere una sessione dopo un reindirizzamento in PHP. Ho già capito la risposta, pubblicandola qui per far sapere agli altri. Perché la mia soluzione non è su StackOverflow.
dayuloli,

2
Va bene, ma questo è un sito di controllo qualità. Per favore, fai una domanda.
jeremy,

Non ho notato che veniva da te. Tuttavia, questo sito è per domande, non per risposte a domande che già conosci.
Aris,


21
@Aris Non è vero, quando le persone hanno una domanda sulla programmazione, vengono a StackOverflow per chiedere aiuto. Se non ci sono risposte disponibili, non possono ottenere l'aiuto di cui hanno bisogno. Sto cercando di fornire quella risposta.
dayuloli,

Risposte:


209

Innanzitutto, esegui questi consueti controlli:

  1. Assicurarsi che session_start();venga chiamato prima di chiamare qualsiasi sessione. Quindi una scommessa sicura sarebbe quella di metterlo all'inizio della tua pagina, immediatamente dopo la <?phpdichiarazione di apertura prima di ogni altra cosa. Assicurati anche che non ci siano spazi bianchi / tab prima della <?phpdichiarazione di apertura .
  2. Dopo il headerreindirizzamento, termina lo script corrente usando exit();(Altri hanno anche suggerito session_write_close();e session_regenerate_id(true), puoi provare anche quelli, ma userei exit();)
  3. Assicurati che i cookie siano abilitati nel browser che stai utilizzando per testarlo.
  4. Assicurati che register_globalssia spento, puoi controllare questo nel php.inifile e anche usando phpinfo(). Fare riferimento a questo su come disattivarlo.
  5. Assicurati di non aver eliminato o svuotato la sessione
  6. Assicurarsi che la chiave nel proprio $_SESSIONarray superglobal non venga sovrascritta da nessuna parte
  7. Assicurati di reindirizzare allo stesso dominio. Quindi il reindirizzamento da a www.yourdomain.coma yourdomain.comnon porta avanti la sessione.
  8. Assicurati che l'estensione del tuo file sia .php(succede!)

Ora, questi sono gli errori più comuni, ma se non hanno funzionato, è molto probabile che il problema riguardi la tua società di hosting. Se tutto funziona localhostma non sul tuo server remoto / di prova, questo è probabilmente il colpevole. Quindi controlla la knowledge base del tuo provider di hosting (prova anche i loro forum ecc.). Per aziende come FatCow e iPage, richiedono di specificare session_save_path. Quindi in questo modo:

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

(sostituisci "il percorso della tua home directory" con il tuo effettivo percorso della home directory. Di solito si trova all'interno del tuo pannello di controllo (o equivalente), ma puoi anche creare un test.phpfile nella tua directory principale e digitare:

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

Il bit prima di "test.php" è il percorso della tua directory home. E, naturalmente, assicurati che la cartella esista effettivamente nella tua directory principale. (Alcuni programmi non caricano cartelle vuote durante la sincronizzazione)


8
+1 ben scritto, se tutto fallisce, basta usare i cookie (generare casualmente una stringa e memorizzarla nel db e usarla come valore del cookie).
Dave Chen,

2
il passaggio tra http andn https potrebbe essere anche essere un problema stackoverflow.com/questions/441496/...
dev.e.loper

4
Nota che a partire da php 5.4.0 register_globals è stato rimosso, quindi non causerà più un problema
anthonygore

2
Controllare anche il log degli errori del server web; nel mio caso, si è verificato un errore "Impossibile scrivere i dati della sessione (file). Verificare che l'impostazione corrente di session.save_path sia corretta". Le autorizzazioni erano errate nella directory save_path.
timbonico

Qual è il motivo per cui le mie sessioni verrebbero archiviate in un posto diverso da session.save_path?
Giustino,

26

dovresti usare "esci" dopo un'intestazione

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

Esiste un bug per Gecko (ad es. Waterfox, Firefox, SeaMonkey) in cui se ci sono output di dati (ad es. echo ' ';) O spazi bianchi di qualsiasi tipo, ignorerà completamente l'intestazione della posizione.
Giovanni

18

Ho provato tutte le possibili soluzioni, ma nessuna ha funzionato per me! Certo, sto usando un servizio di hosting condiviso.

Alla fine, ho risolto il problema usando "url relativo" nell'intestazione di reindirizzamento!

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

annullato i cookie di sessione

header("location: index.php")

ha funzionato come un fascino!


7

Ho avuto lo stesso problema. Ci ho lavorato diverse ore e mi ha fatto impazzire.

Nel mio caso il problema era un 404 chiamato a causa della mancanza di favicon.ico solo su Chrome e Firefox. Gli altri navigatori hanno funzionato bene.


Volevo solo ringraziarti per questa risposta, mi ha fatto capire che 404 richieste di immagini venivano inoltrate da Varnish a PHP senza cookie e quindi venivano costantemente create nuove sessioni. Potrei non averlo mai capito senza di te.
Pascal Zajac,

Ho avuto lo stesso problema, il mio favicon.ico veniva reindirizzato (302 reindirizzamento dal sottodominio al dominio principale) e, quindi, ogni volta generava una nuova sessione. Molte grazie!
simdrouin,

4

Quando uso il percorso relativo "dir / file.php" con nella funzione header () funziona per me. Penso che la sessione non venga salvata per qualche motivo quando si reindirizza utilizzando l'URL completo ...

//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

Questo mi ha sorpreso per molto tempo (e questo post è stato fantastico da trovare!) Ma per chiunque non riesca ancora a far funzionare le sessioni tra i reindirizzamenti delle pagine per funzionare ... Ho dovuto andare nel file php.ini e attivare i cookie :

session.use_cookies = 1 

Pensavo che le sessioni funzionassero senza cookie ... in effetti so che DOVREBBE ... ma questo ha risolto il mio problema almeno fino a quando non riuscirò a capire cosa potrebbe succedere nel quadro generale.


Non sapevo che le sessioni potessero funzionare senza cookie! Impara qualcosa di nuovo ogni giorno! programmerinterview.com/index.php/php-questions/…
dayuloli

ovviamente POSSONO funzionare senza cookie dipende dalla tua configurazione. Ma dovresti sapere cosa fai. E hai una buona ragione per farlo. Perché è meno sicuro. e nel caso in cui devi lavorare per qualsiasi motivo senza cookie. Dovresti almeno configurare ini_set ('session.use_strict_mode', '1'); e generalmente hanno una breve durata della sessione e dopo il login dell'utente usa session_regenerate_id (). Ma tieni presente che se alcuni utenti pubblicano un link a un sito sul tuo server in un forum, le persone che effettivamente fanno clic su questo link si occuperanno della sessione. Forse è anche una buona idea controllare l'ip.
Michael,

3

Ho avuto un problema simile, anche se il mio contesto era leggermente diverso. Avevo una configurazione di sviluppo locale su una macchina il cui nome host era windowse l'indirizzo IP era 192.168.56.2.

Potrei accedere al sistema usando uno di:

Dopo aver effettuato l'accesso, il mio codice PHP reindirizzava usando:

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

Se il precedente nome di dominio utilizzato per accedere al sistema non lo fosse windows, i dati della sessione andrebbero persi. Ho risolto questo cambiando il codice in:

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

Ora funziona indipendentemente dal nome di dominio locale o dall'indirizzo IP inserito dall'utente.

Spero che questo possa essere utile a qualcuno.


3

Ho riscontrato questo problema in una determinata pagina. Stavo impostando i valori di $ _SESSION in altre pagine prima del reindirizzamento e tutto funzionava bene. Ma questa pagina particolare non funzionava.

Alla fine mi sono reso conto che in questa particolare pagina stavo distruggendo la sessione all'inizio della pagina ma non la riavviavo mai più. Quindi la mia funzione di distruzione è cambiata da:

function sessionKill(){

    session_destroy();

}

per:

function sessionKill(){

    session_destroy();
    session_start();

}

E tutto ha funzionato!


3

Avevo lo stesso problema. Improvvisamente ALCUNE delle variabili della mia sessione non sarebbero persistenti alla pagina successiva. Il problema si è rivelato essere (in php7.1) la posizione dell'intestazione non deve contenere WWW, ad esempio https: // mysite . va bene, https: //www.mysite . perderà le variabili di sessione delle pagine. Non tutto, solo quella pagina.


Questo perché www.mysite.comè visto come un dominio completamente diverso rispetto blog.mysite.como semplicementemysite.com
dayuloli,

2

Ho lottato con questo per giorni, controllando / provando tutte le soluzioni, ma il mio problema era che non avevo richiamato session_start();dopo il reindirizzamento. Ho appena pensato che la sessione fosse "ancora viva".

Quindi non dimenticarlo!


Sì! questo era anche il mio problema. Pensavo che iniziare una sessione PHP fosse come accendere una luce per tutta la casa. Non avevo capito che dovevi girare l'interruttore per ogni stanza in cui entri.
Dale Thompson,

1

Ho avuto lo stesso problema e ho trovato il modo più semplice. Ho semplicemente reindirizzato a un reindirizzamento .html con 1 linea di JS

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

invece di PHP

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

Spero che aiuti.

Grammo d'amore


1

Se stai usando session_set_cookie_params()potresti voler verificare se stai passando il quarto parametro $securecome true. In tal caso, è necessario accedere all'URL utilizzando https.

Il $secureparametro essendo vero indica che la Sessione è disponibile solo all'interno di una richiesta sicura. Ciò potrebbe interessarti a livello locale più che in ambienti di produzione o stage.

Menzionandolo perché ho trascorso gran parte della giornata cercando di trovare questo problema, e questo è quello che mi ha risolto. Sono stato appena aggiunto a questo progetto e nessuno ha detto che richiedeva https.

Quindi puoi usare https localmente, oppure puoi impostare il $secureparametro su FALSEe quindi usare http localmente. Assicurati di ripristinarlo su true quando spingi le modifiche verso l'alto.

A seconda del server locale, potrebbe essere necessario modificarlo DocumentRootnel httpd-ssl.confserver in modo che l'URL locale venga pubblicato https.


1

Un'altra possibile ragione:

Questo è lo spazio di archiviazione del mio server. Lo spazio su disco del mio server si riempie. Quindi, ho rimosso alcuni file e cartelle nel mio server e ho provato.

Funzionava !!!

Sto salvando la mia sessione in AWS Dynamo DB, ma mi aspetto ancora un po 'di spazio nel mio server per elaborare la sessione. Non so perché !!!


1

Se si utilizza Laravel e si riscontra questo problema, è necessario salvare i dati della sessione prima di reindirizzare.

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

0

Ho anche avuto lo stesso problema con il reindirizzamento non funzionante e ho provato tutte le soluzioni che ho trovato, il mio reindirizzamento dell'intestazione veniva utilizzato in un modulo.

L'ho risolto inserendo il reindirizzamento dell'intestazione in una diversa pagina php 'signin_action.php' e passando i parametri delle variabili attraverso i parametri desiderati in url e quindi riassegnandoli nel modulo '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';
}

?>

Non è una bella soluzione ma ha funzionato.


0

Per me l'errore è stato che ho cercato di salvare un oggetto non serializzabile nella sessione in modo da generare un'eccezione durante il tentativo di scrivere la sessione. Ma poiché tutto il mio codice di gestione degli errori aveva già interrotto qualsiasi operazione, non ho mai visto l'errore.

Potrei trovarlo nei log degli errori di Apache, però.


0

Solo per la cronaca ... ho avuto questo problema e dopo alcune ore di tentare tutto il problema era che il disco era pieno e che le sessioni php non potevano essere scritte nella directory tmp ... quindi se hai questo problema controlla che pure...


Questa risposta ha funzionato per me. Eseguiamo un'immagine Amazon Machine con nginx. Sembra che ci sia un errore nel fatto che la cartella della sessione non sia di proprietà dell'utente corretto (nel nostro caso www), quindi eseguire chown -R www.wwwsulla cartella delle sessioni risolve il problema.
Joshua,

0

Per me, Firefox ha memorizzato l'id di sessione (PHPSESSID) in un cookie, ma Google Chrome ha utilizzato il parametro GET o POST. Quindi devi solo assicurarti che lo script di ritorno (per me: checkout paypal) commetta PHPSESSID nel parametro url o POST.


0

Dopo aver provato molte soluzioni qui su SO e altri blog ... ciò che ha funzionato per me è stato aggiungere .htaccess alla radice del mio sito web.

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

0

Se stai usando Wordpress, ho dovuto aggiungere questo hook e avviare la sessione su init:

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

0

Niente ha funzionato per me, ma ho trovato ciò che ha causato il problema (e risolto):

Controlla i cookie del tuo browser e assicurati che non ci siano cookie di sessione php su diversi sottodomini (come uno per " www.website.com " e uno per " website.com ").

Ciò è stato causato da un javascript che ha erroneamente utilizzato il sottodominio per impostare i cookie e aprire le pagine in iframe.


0

Prima di tutto, assicurati di chiamare session_start()prima di utilizzare la $_SESSIONvariabile.

Se hai disabilitato la segnalazione degli errori, prova ad attivare e vedere il risultato.

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

Le ragioni più comuni che non sono menzionate nella risposta di @ dayuloli:

  1. Problema di spazio su disco. Assicurarsi che lo spazio su disco non sia pieno, è necessario dello spazio per archiviare i file di sessione.

  2. La directory della sessione potrebbe non essere scrivibile. Puoi verificarlo conis_writable(session_save_path())


0

Stavo avendo lo stesso problema e sono impazzito cercando nel mio codice la risposta. Finalmente ho trovato il mio hosting recentemente aggiornato la versione di PHP sul mio server e non ho impostato correttamente il session_save_pathparametro sul php.inifile.

Quindi, se qualcuno legge questo, si prega di controllare la php.iniconfigurazione prima di ogni altra cosa.


0

Assicurarsi che session_write_closenon venga chiamato tra session_start()e quando si imposta la sessione.

session_start();

[...]

session_write_close();

[...]

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

0

Ora che il GDPR è una cosa, le persone che visitano questa domanda probabilmente usano uno script di cookie. Bene, quella sceneggiatura ha causato il problema per me. Apparentemente, PHP utilizza un cookie chiamato PHPSESSIDper tracciare la sessione. Se lo script lo elimina, perdi i tuoi dati.

Ho usato questo script cookie . Ha un'opzione per abilitare i cookie "essenziali". Ho aggiunto PHPSESSIDall'elenco, lo script ha smesso di eliminare il cookie e tutto ha ripreso a funzionare.

Probabilmente si può abilitare alcune impostazioni PHP per evitare di usare PHPSESSID, ma se lo script cookie è la causa del problema, perché non risolvere quello .


0

Ho risolto questo problema dopo molti giorni di debug ed era tutto perché il mio URL di ritorno proveniente da PayPal Express Checkout non aveva un "www". Chrome ha riconosciuto che i domini dovrebbero essere trattati allo stesso modo, ma altri browser a volte no. Quando si utilizzano sessioni / cookie e percorsi assoluti, non dimenticare il 'www'!


0

Ho risolto dando autorizzazioni di scrittura di gruppo al percorso in cui archiviare i file di sessione di PHP. È possibile trovare il percorso della sessione con la funzione session_save_path ().


0

Oggi ho avuto questo problema in un progetto e ho dovuto cambiare questo parametro in falso (o rimuovere le linee, per impostazione predefinita è disabilitato):

ini_set( 'session.cookie_secure', 1 );

Ciò è accaduto perché il progetto attuale funziona su http e non solo su https. Ulteriori informazioni sono disponibili nella documentazione http://php.net/manual/en/session.security.ini.php


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

Troppo tardi per rispondere, ma questo ha funzionato per me


0

Per me questo è stato un errore di autorizzazione e questo l'ha risolto:

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

Ho provato alcune ore su PHP e l'ultimo test che ho fatto è stato che ho creato due file session1.php e session2.php.

session1.php:

session_start();

$_SESSION["user"] = 123;

header("Location: session2.php");

session2.php:

session_start();

print_r($_SESSION);

e stava stampando un array vuoto.

A questo punto, ho pensato che potesse trattarsi di un problema del server e in effetti lo era.

Spero che questo aiuti qualcuno.


1
Il chown è una BAD soluzione, in quanto tornerà al valore predefinito all'aggiornamento del pacchetto. Vedere i commenti nella configurazione predefinita del pool (www.conf). Modo corretto se si utilizza un'altra directory diversa da quella di Apache (es: / var / lib / php / nginx / session)
Remi Collet

Hai ragione. l'aggiornamento del pacchetto è stato il motivo del mio problema in primo luogo. Ma dato che è stato così e ho avuto bisogno di una soluzione rapida che mi ha aiutato. Il mio amministratore SYS lo ha risolto, non sono quasi bravo con Linux.
temo
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.