PHP: Archiviazione di "oggetti" all'interno di $ _SESSION

Question

Ho appena capito che in realtà posso archiviare oggetti nella $ _SESSION e lo trovo abbastanza interessante perché quando salto in un'altra pagina ho ancora il mio oggetto. Ora, prima di iniziare a utilizzare questo approccio, vorrei scoprire se è davvero una buona idea o se ci sono potenziali insidie ??.

So che se avessi un singolo punto di entrata non avrei bisogno di farlo ma non ci sono ancora, quindi non ho un solo punto di entrata e vorrei davvero mantenere il mio oggetto perché Non perdo il mio stato in quel modo. (Ora ho anche letto che dovrei programmare siti senza stato ma non capisco ancora questo concetto.)

Quindi in breve : è possibile archiviare oggetti nella sessione, ci sono problemi con esso?

---

Modifica:

Riepilogo temporaneo : Ormai capisco che probabilmente è meglio ricreare l'oggetto anche se si tratta di interrogare nuovamente il database.

Ulteriori risposte potrebbero forse approfondire quell'aspetto un po 'di più!

Answer 1

So che questo argomento è vecchio, ma questo problema continua a presentarsi e non è stato affrontato con mia soddisfazione:

Sia che si salvino oggetti in $ _SESSION, sia che si ricostruisca l'intero tessuto in base ai dati nascosti nei campi modulo nascosti, o si eseguano nuovamente query dal DB ogni volta, si utilizza state. HTTP è apolide (più o meno; ma vedi GET vs. PUT) ma quasi tutto ciò che a qualcuno interessa fare con un'app Web richiede che lo stato sia mantenuto da qualche parte. Agire come se spingere lo stato in angoli e fessure equivale a una sorta di vittoria teorica è semplicemente sbagliato. Lo stato è stato. Se si utilizza lo stato, si perdono i vari vantaggi tecnici ottenuti dall'apolidia. Questo non è qualcosa per cui perdere il sonno a meno che tu non sappia in anticipo che dovresti perdere il sonno.

Sono particolarmente turbato dalla benedizione ricevuta dal "double whammy" argomenti sollevati da Hank Gay. L'OP sta creando un sistema di e-commerce distribuito e bilanciato in base al carico? La mia ipotesi è no; e affermerò inoltre che la serializzazione della sua classe $ User, o qualsiasi altra cosa, non paralizzerà il suo server oltre la riparazione. Il mio consiglio: utilizzare tecniche sensibili alla propria applicazione. Gli oggetti in $ _SESSION vanno bene, soggetti a precauzioni di buon senso. Se la tua app si trasforma improvvisamente in qualcosa che rivaleggia con Amazon nel traffico servito, dovrai adattarti di nuovo. È la vita.

Answer 2

è OK fintanto che al momento della chiamata session_start (), la dichiarazione / definizione della classe è già stata rilevata da PHP o può essere trovata da un caricatore automatico già installato. altrimenti non sarebbe in grado di deserializzare l'oggetto dall'archivio sessioni.

Answer 3

HTTP è un protocollo senza stato per un motivo. Stato della saldatura delle sessioni su HTTP. Come regola generale, evitare di utilizzare lo stato della sessione.

UPDATE: Non esiste un concetto di sessione a livello HTTP; i server forniscono questo fornendo al client un ID univoco e dicendo al client di inviarlo nuovamente ad ogni richiesta. Quindi il server utilizza tale ID come chiave in una grande hashtable di oggetti Session. Ogni volta che il server riceve una richiesta, cerca le informazioni sulla sessione dalla sua hashtable di oggetti sessione in base all'ID che il client ha inviato con la richiesta. Tutto questo lavoro extra è un doppio scemo sulla scalabilità (un grande motivo per cui HTTP è apolide).

• Whammy One: riduce il lavoro che un singolo server può fare.
• Whammy Two: rende più difficile il ridimensionamento perché ora non puoi semplicemente indirizzare una richiesta a un vecchio server - non hanno tutti la stessa sessione. È possibile aggiungere tutte le richieste con un determinato ID sessione allo stesso server. Non è facile ed è un singolo punto di errore (non per il sistema nel suo complesso, ma per grossi blocchi di utenti). In alternativa, è possibile condividere l'archiviazione di sessione su tutti i server nel cluster, ma ora si ha una maggiore complessità: memoria collegata in rete, un server di sessione autonomo, ecc.

Detto questo, maggiore è il numero di informazioni inserite nella sessione, maggiore è l'impatto sulle prestazioni (come sottolinea Vinko). Inoltre, come sottolinea Vinko, se il tuo oggetto non è serializzabile, la sessione si comporterà male. Quindi, come regola generale, evita di mettere più del necessario nella sessione.

@Vinko Di solito puoi aggirare lo stato di archivio del server incorporando i dati che stai monitorando nella risposta che invii e facendo in modo che il client lo reinvii, ad esempio inviando i dati in un input nascosto. Se veramente hai bisogno del tracciamento dello stato sul lato server, probabilmente dovrebbe trovarsi nel tuo archivio dati di backup.

(aggiunge Vinko: PHP può utilizzare un database per archiviare le informazioni sulla sessione e fare in modo che il client reinvia i dati ogni volta potrebbe risolvere potenziali problemi di scalabilità, ma apre una grande lattina di problemi di sicurezza a cui devi prestare attenzione ora che il client è controllo di tutto il tuo stato)

Answer 4

• Gli oggetti che non possono essere serializzati (o che contengono membri non serializzabili) non usciranno da $ _SESSION come ci si aspetterebbe
• Le sessioni enormi mettono a dura prova il server (serializzare e deserializzare mega di stato ogni volta è costoso)

A parte questo, non ho visto problemi.

Answer 5

Nella mia esperienza, generalmente non ne vale la pena per qualcosa di più complicato di una StdClass con alcune proprietà. Il costo della non serializzazione è sempre stato più che ricreare da un database dato un identificatore memorizzato nella sessione. Sembra interessante, ma (come sempre), la profilazione è la chiave.

Answer 6

Suggerirei di non usare lo stato a meno che tu non ne abbia assolutamente bisogno. Se riesci a ricostruire l'oggetto senza usare le sessioni, fallo. Avere stati nella tua applicazione web rende l'applicazione più complessa da compilare, per ogni richiesta devi vedere in che stato si trova l'utente. Naturalmente ci sono momenti in cui non puoi evitare di usare la sessione (esempio: l'utente deve mantenere l'accesso durante la sua sessione su l'applicazione web). Infine, suggerirei di mantenere l'oggetto sessione il più piccolo possibile in quanto influisce sulle prestazioni per serializzare e annullare la serializzazione di oggetti di grandi dimensioni.

Answer 7

Dovrai ricordare che i tipi di risorse (come connessioni db o puntatori di file) non persistono tra i caricamenti di pagina e dovrai ricrearli invisibilmente.

Considera anche la dimensione della sessione, a seconda di come è memorizzata, potresti avere restrizioni di dimensione o problemi di latenza.

Answer 8

Sollevo anche quando aggiorno le librerie del software - abbiamo aggiornato il nostro software e la vecchia versione aveva oggetti in sessione con i nomi delle classi del software V1, il nuovo software si arrestava in modo anomalo quando tentava di costruire gli oggetti che erano nella sessione - poiché il software V2 non utilizzava più quelle stesse classi, non riusciva a trovarle. Abbiamo dovuto inserire un codice di correzione per rilevare gli oggetti sessione, eliminare la sessione se trovata, ricaricare la pagina. Il dolore più grande inizialmente ti dispiace che stavi ricreando questo bug quando è stato segnalato per la prima volta (fin troppo familiare, "beh, funziona per me" :) in quanto riguardava solo le persone che recentemente entravano e uscivano dai vecchi e dai nuovi sistemi, tuttavia, buon lavoro l'abbiamo trovato prima del lancio dato che tutti i nostri utenti avrebbero sicuramente avuto le vecchie variabili di sessione nelle loro sessioni e avrebbero potuto potenzialmente andare in crash per tutti, sarebbe stato un lancio terribile :)

Comunque, come suggerisci nel tuo emendamento, penso anche che sia meglio ricreare l'oggetto. Quindi forse solo archiviare l'id e poi su ogni richiesta che estrae l'oggetto dal database, è meglio / più sicuro.