Dati sessione PHP non salvati

StackOverflow https://stackoverflow.com/questions/155920

  •  03-07-2019
  •  | 
  •  

Domanda

Ho una di quelle " giuro che non ho toccato il server " situazioni. Onestamente non ho toccato nessuno degli script php. Il problema che sto riscontrando è che i dati php non vengono salvati su diverse pagine o aggiornamenti di pagine. So che una nuova sessione è stata creata correttamente perché posso impostare una variabile di sessione (ad esempio $ _SESSION ['foo'] = & Quot; foo & Quot; e stamparla nuovamente sulla stessa pagina, ma va bene. quando provo ad usare la stessa variabile su un'altra pagina non è impostata! Esistono funzioni o informazioni php che posso usare sul mio server host per vedere cosa sta succedendo?

Ecco uno script di esempio che al momento non funziona sul server dei miei host: 

<?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 variabile 'viste' non viene mai incrementata dopo aver effettuato un aggiornamento della pagina. Sto pensando che questo sia un problema dalla loro parte, ma prima volevo assicurarmi di non essere un completo idiota.

Ecco il phpinfo () per il server dei miei host (PHP versione 4.4.7): alt text

È stato utile?

Soluzione

Grazie per tutte le informazioni utili. Si scopre che il mio host ha cambiato server e ha iniziato a utilizzare un percorso di salvataggio della sessione diverso da / var / php_sessions che non esisteva più. Una soluzione sarebbe stata quella di dichiarare ini_set(' session.save_path','SOME WRITABLE PATH'); in tutti i miei file di script, ma sarebbe stato un problema. Ho parlato con l'host e hanno impostato esplicitamente il percorso della sessione su un percorso reale che esisteva. Spero che questo aiuti chiunque abbia problemi con il percorso della sessione.

Altri suggerimenti

Verifica di non mischiare https: // con http: //. Le variabili di sessione non scorrono tra sessioni sicure e non sicure.

Ha avuto lo stesso problema: ciò che mi è successo è che il nostro amministratore del server ha cambiato il session.cookie_secure booleano in Attivo, il che significa che i cookie verranno inviati solo tramite una connessione sicura. Dato che il cookie non veniva trovato, php stava creando una nuova sessione ogni volta, quindi le variabili di sessione non venivano visualizzate.

Usa phpinfo() e controlla le session.* impostazioni.

Forse le informazioni sono memorizzate nei cookie e il tuo browser non accetta i cookie, qualcosa del genere.

Controlla prima quello e torna con i risultati.

Puoi anche fare un & nbsp; print_r($_SESSION); per avere un dump di questa variabile e vedere il contenuto ....

Per quanto riguarda il tuo session.save_path, <=> è valido? Il tuo server web ha accesso in scrittura a questa directory?

Spero che questo aiuti.

Ho avuto il seguente problema

index.php 

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

index2.php 

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

La variabile $_SESSION['a'] non è stata impostata correttamente. Quindi ho modificato index.php di conseguenza 

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

Non so cosa significhi internamente, lo spiego a me stesso che il cambio della variabile di sessione non è stato abbastanza veloce :)

Verifica se il percorso di salvataggio della sessione è scrivibile dal server web.

Assicurati di aver attivato i cookie .. (dimentico quando li spengo per testare qualcosa)

Usa firefox con l'estensione firebug per vedere se il cookie viene impostato e ritrasmesso.

E su una nota non correlata, inizia a guardare php5, perché php 4.4.9 è l'ultimo della serie php4.

Verifica chi sono il gruppo e il proprietario della cartella in cui viene eseguito lo script. Se l'id gruppo o l'id utente sono errati, ad esempio, impostato su root, le sessioni non verranno salvate correttamente.

Controlla il valore di " views " quando prima lo incrementi. Se, per qualche bizzarro motivo, viene impostato su una stringa, quindi quando aggiungi 1 ad essa, restituirà sempre 1. 

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

Bene, possiamo eliminare l'errore di codice perché ho testato il codice sul mio server (PHP 5).

Ecco cosa controllare:

  1. Stai chiamando session_unset () o session_destroy () ovunque? Queste funzioni elimineranno immediatamente i dati della sessione. Se le inserisco alla fine della mia sceneggiatura, inizia a comportarsi esattamente come le descrivi.

  2. Funziona allo stesso modo in tutti i browser? Se funziona su un browser e non su un altro, potresti avere un problema di configurazione sul browser non funzionante (ovvero hai disattivato i cookie e hai dimenticato di accenderli o stai bloccando i cookie per errore).

  3. La cartella della sessione è scrivibile? Non puoi provarlo con is_writable (), quindi dovrai andare nella cartella (da phpinfo () sembra / var / php_sessions) e assicurarti che le sessioni vengano effettivamente create.

Se imposti una sessione in php5, prova a leggerla su una pagina php4, potrebbe non apparire nel posto giusto! Rendi le pagine la stessa versione php o imposta session_path.

Ho passato anni a cercare la risposta per un problema simile. Non è stato un problema con il codice o l'installazione, in quanto un codice molto simile funzionava perfettamente in un altro .php sullo stesso server. Si è scoperto che il problema è stato causato da una grande quantità di dati salvati nella sessione in questa pagina. In un punto avevamo una linea come questa: $_SESSION['full_list'] = $full_list dove $full_list era una matrice di dati caricati dal database; ogni riga era un array di circa 150 elementi. Quando il codice è stato inizialmente scritto un paio di anni fa, il DB conteneva solo circa 1000 righe, quindi <=> conteneva circa 100 elementi, ognuno dei quali era un array di circa 20 elementi. Con il tempo, i 20 elementi sono stati trasformati in 150 e 1000 righe trasformate in 17000, quindi il codice ha archiviato quasi 64 mega dati nella sessione. Apparentemente, con questa quantità di dati archiviati, si è rifiutato di archiviare qualsiasi altra cosa. Una volta modificato il codice per gestire i dati localmente senza salvarli nella sessione, tutto ha funzionato perfettamente.

  

Conosco una soluzione che ho trovato (OSX con Apache 1 e appena passato a PHP5) quando ho avuto un problema simile era che il disinserimento di 1 chiave specifica (ovvero disinserimento ($ _ SESSION ['chiave']);) non lo causava salvare. Non appena non ho più disattivato quella chiave, questa è stata salvata. Non l'ho mai più visto, tranne su quel server su un altro sito, ma poi era una variabile diversa. Né era niente di speciale.

Grazie per questo Darryl. Questo mi ha aiutato. Stavo eliminando una variabile di sessione e per qualche motivo stava impedendo alla sessione di impegnarsi. ora sto solo impostandolo su null (il che va bene per la mia app), e funziona.

Conosco una soluzione che ho trovato (OSX con Apache 1 e appena passato a PHP5) quando ho avuto un problema simile era che il disinserimento di 1 chiave specifica (ovvero disinserimento ($ _ SESSION ['chiave']);) non lo causava salvare. Non appena non ho più disattivato quella chiave, questa è stata salvata. Non l'ho mai più visto, tranne su quel server su un altro sito, ma poi era una variabile diversa. Né era niente di speciale.

Ecco un problema comune che non ho visto risolto negli altri commenti: il tuo host esegue una cache di qualche tipo? Se stanno automaticamente memorizzando nella cache i risultati in qualche modo, otterresti questo tipo di comportamento.

Volevo solo aggiungere una piccola nota che ciò può accadere anche se perdi accidentalmente l'istruzione session_start () sulle tue pagine.

Il percorso del cookie di sessione era impostato su " // " anziché " / " ;. Firebug è fantastico. Spero che aiuti qualcuno.

Ho avuto questo problema durante l'utilizzo di pagine sicure da cui provenivo da www.domain.com/auth.php che reindirizzavano a domain.com/destpage.php. Ho rimosso il www dal link auth.php e ha funzionato. Questo mi ha gettato perché tutto ha funzionato diversamente; la sessione non è stata impostata quando sono arrivato a destinazione.

Un problema comune spesso trascurato è anche che non ci devono essere altri codici o spazi aggiuntivi prima del comando session_start ().

Ho riscontrato questo problema in precedenza in cui avevo una riga vuota prima di session_start () che non faceva funzionare correttamente.

Aggiunta della mia soluzione:

Controlla se accedi al dominio corretto . Stavo usando www.mysite.com per iniziare la sessione e ho provato a riceverlo da mysite.com (senza www).

Ho risolto questo aggiungendo una riscrittura htaccess di tutti i domini su www per essere sul lato / sito sicuro.

Controlla anche se usi http o https.

Modifica il tuo php.ini.
Penso che il valore di session.gc_probability sia 1, quindi impostalo su 0. 

session.gc_probability=0

Verifica se stai utilizzando session_write_close (); ovunque, lo stavo usando subito dopo un'altra sessione e poi cercavo di scrivere di nuovo alla sessione e non funzionava .. quindi basta commentare che sh * t fuori

Altre poche cose che dovevo fare (avevo lo stesso problema: nessuna conservazione dei sessoni dopo l'aggiornamento di PHP alla 5.4). Molti non ne hanno bisogno, a seconda di cosa contiene php.ini del server (controlla 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

Fondamentalmente, php.ini dovrebbe essere impostato su nessun cookie e i parametri della sessione devono essere coerenti con ciò che osc vuole.

Potrebbe anche essere necessario modificare alcuni snippet di codice di sessione in application_top.php - creando oggetti in cui non esiste nessuno nelle chiamate tep_session_is_registered (...) (ad es. oggetto di navigazione), impostare le variabili $ HTTP_ sul nuovo $ _SERVER quelli e alcuni altri test isset per oggetti vuoti (google per informazioni). Ho finito per essere in grado di utilizzare i file session.php originali (include / classi e include / funzioni) con un application_top.php leggermente modificato per far ripartire le cose. Le impostazioni di php.ini erano il problema principale, ma questo ovviamente dipende da ciò che la tua azienda server ha installato come impostazioni predefinite.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top