Le variabili di sessione dovrebbero essere evitate?

36

In passato facevo molto affidamento sulle variabili di sessione, ma recentemente ne ho trovate molte inutili, usando invece cose come i parametri della stringa di query.

Un mio collega si rifiuta di utilizzare le variabili di sessione. È un obiettivo realistico e le variabili di sessione dovrebbero essere evitate per qualsiasi motivo pratico? È possibile evitare completamente le variabili di sessione (ad eccezione dei cookie di sessione per consentire gli accessi) e ciò comporterebbe progetti migliori?

Alcuni dei motivi per cui il mio collega non li usa:

Natura non tipizzata delle variabili di sessione
Timeout della sessione che causano la perdita di stato
Natura dell'ambito globale delle variabili di sessione
Server di bilanciamento del carico che perdono sessioni (.Net specifico?)
Riavvio di pool di applicazioni / server
Non sono necessari

web-development design

— Tjaart
fonte

3

using things like query string parameters instead- In questo caso, utilizzare sempre sempre i parametri della stringa di query, se possibile. L'uso della sessione per quel tipo di parametro è fragile e può introdurre strani bug quando gli utenti hanno più schede aperte.

— Izkata,

2

raccomandazione personale - non ricevere alcun consiglio dal tuo collega in quanto chiaramente non sa di cosa sta parlando. Timeout della sessione? Non capisce che le durate delle sessioni sono controllate dall'app Web?

— GrandmasterB,

2

@GrandmasterB Ahem. O non sa cosa stanno facendo o è stato bruciato da ciascuno di quei punti elenco nel corso della loro carriera (io stesso ne ho colpiti 4) e conosce i modi più appropriati per gestire lo stato temporaneo.

— Ed James,

Qualcuno potrebbe spiegare la relazione tra lo stato della sessione e l'apertura di più schede? Quando apri una nuova scheda, contiene o contiene ora lo stato della scheda precedente? Grazie.

— Ray,

41

Se hai una variabile di sessione nella tua applicazione, chiediti questo:

Quando faccio clic sul pulsante Indietro del mio browser, quale valore desidero avere la mia variabile?

Se la risposta è "il valore corrente", le variabili di sessione potrebbero essere utili. Un esempio potrebbe essere un carrello: non ti aspetti che le cose vengano rimosse dal carrello mentre ripercorri la storia. È sempre nel suo stato attuale.

Se la risposta è "un valore precedente", non dovresti usare le variabili di sessione. I cattivi usi che ho visto includono il passaggio di un parametro tra le pagine. Se faccio clic sul pulsante Indietro per tornare a una pagina, la pagina non ottiene necessariamente il parametro corretto. Inoltre, se apro due schede, come si comporterà il mio sito?

Ottenere il comportamento corretto del pulsante Indietro non è affatto il tutto e per tutto, ma ti aiuta a pensare a un sito web come a un'applicazione senza stato. In generale, trovo che gli usi appropriati delle variabili di sessione siano pochi e lontani tra loro.

— Tim
fonte

Sono d'accordo. Una volta che si pensa alla semantica desiderata con più schede, di solito diventa ovvio se le variabili di sessione o i parametri di richiesta sono la scelta giusta.

— CodesInChaos,

Ho visto esattamente questi tipi di errori con le variabili di sessione e, certamente, ho imparato a mie spese.

— Tjaart,

Quando un utente preme il pulsante Indietro, si aspettano che gli articoli rimangano nel carrello fino alla scadenza della loro sessione o desiderano che gli articoli rimangano finché non vengono rimossi? L'utilizzo di altri meccanismi di persistenza (come un database) consentirebbe la persistenza oltre la singola sessione e il pulsante Indietro continuerebbe a funzionare come previsto dall'utente.

— Lawtonfogle,

25

Il protocollo HTTP è senza stato. Le sessioni sono un modo per preservare lo stato del client attraverso le richieste HTTP. Puoi scegliere di farlo con la gestione della sessione integrata di una piattaforma o farlo tu stesso con i parametri della stringa di query. In entrambi i casi è necessario un concetto di sessione per molte attività.

Probabilmente al tuo collega non piace un'implementazione specifica o non ha utilizzato le sessioni per gli scopi previsti. Se è necessario conservare le informazioni su una specifica connessione client attraverso richieste HTTP, è necessaria una qualche forma di persistenza della sessione.

I seguenti problemi sono specifici dell'implementazione:

Natura non tipizzata delle variabili di sessione

Natura dell'ambito globale delle variabili di sessione

Server di bilanciamento del carico che perdono sessioni

Riavvio di pool di applicazioni / server

Ad esempio, lavoro spesso in PHP e memorizzo le informazioni sulla mia sessione in un database relazionale. Quindi le mie variabili di sessione vengono digitate. Il bilanciamento del carico e il riavvio del server non causano problemi di sessione.

Questo è più interessante:

Timeout della sessione che causano la perdita di stato

Le sessioni sono spesso conservate tramite i cookie. Questi possono essere eliminati dal cliente in qualsiasi momento. Ma possono anche essere preservati tramite un parametro della stringa di query e quindi non andare mai in timeout sul client. Il timeout del server dipende da te. Quindi anche questo problema è specifico dell'implementazione.

Non buttiamo via l'intero concetto di sessioni solo perché non ci piace un'implementazione particolare. Qualsiasi buon framework di applicazioni Web faciliterà l'utilizzo corretto delle sessioni per preservare gli accessi degli utenti o conservare qualsiasi altra cosa specifica per la visita corrente dell'utente. Il record del database di un utente può (e dovrebbe) essere utilizzato per archiviare elementi specifici al momento dell'accesso. I visitatori anonimi, tuttavia, possono avere informazioni temporanee che vale la pena conservare anche nella loro sessione, come un breve elenco di pagine recenti visitate o la preferenza per nascondi un avviso che hanno già visto. Generalmente solo le informazioni temporanee più piccole sono appropriate per l'archiviazione della sessione.

— Matt S
fonte

Ad essere sincero, ho avuto un'esperienza limitata con i framework oltre a .Net. .Net smette di forzare un valore di timeout per le sessioni. Le variabili di sessione compaiono anche nel codice lato server come un dizionario non tipizzato. Di solito avvolgo questo dizionario in classi correttamente digitate, quindi non vedo neanche questo come un problema. Hai dichiarato di archiviare le informazioni sulla sessione nel database. In ASP .Net l'archiviazione viene gestita diversamente, nel client .Net, nel database (gestito automaticamente) o in un servizio Windows separato.

— Tjaart,

Puoi fornire alcuni esempi di scopi previsti per le sessioni?

— Tjaart,

@Tjaart: ho ampliato un po 'l'ultimo paragrafo. Spero che sia d'aiuto.

— Matt S

14

Altri hanno sottolineato molti punti (che eviterò di ripetere), ma c'è un aspetto della tecnica del tuo amico che non è stato ancora discusso: la sicurezza .

È impossibile sapere che tipo di vulnerabilità si apre senza guardare il codice, ma ecco alcune cose che mi vengono in mente dalla testa.

Fissazione della sessione : un attacco potente che è leggermente più semplice se si può semplicemente fare in modo che l'utente faccia clic su un collegamento che ha già le informazioni necessarie nell'URL (anziché cercare di far sì che l'utente usi una macchina che ha i suoi cookie impostati in modo appropriato).
Iniezione SQL (o altri input dannosi) : non fidarti mai di nulla che provenga dall'utente. Le variabili di sessione hanno il vantaggio di non lasciare mai il server, quindi l'utente non può modificarle direttamente. Mentre devi disinfettare i dati prima di inserirli nella sessione, puoi sempre fidarti dei valori che ottieni successivamente. Se tutto viene passato attraverso la stringa di query, hai MOLTO convalida che devi fare per assicurarti di non accettare input dannosi.
Corruzione dei dati mediante input falsificati : simile all'iniezione SQL, quanti dati vengono trasmessi avanti e indietro? Quanto è cruciale? Posso modificare il comportamento della tua app modificando un valore nella stringa di query? Posso corrompere i dati sul tuo server modificando i valori? Se riesco a corrompere i dati sul server, interesserà altri utenti? (Se la tua risposta è stata "no", la mia risposta è "sei sicuro? Hai molti posti che devi controllare.").

Tutto ciò può ancora accadere quando usi Sessioni, ma possono diventare molto più facili se il tuo amico non sa cosa sta facendo.

— riwalk
fonte

2

Le variabili di sessione sono come le vecchie variabili globali di base in una certa misura. L'onere è a carico dell'utente di tenerne traccia, cosa contiene, portata e modalità di utilizzo; proprio come nelle vecchie versioni di BASIC. Detto questo, perché qualcuno dovrebbe assolutamente scartare l'uso di un meccanismo che è ovviamente progettato per essere parte integrante e molto importante del modello di programmazione (ASP, MVC ecc.)?

L'unica cosa negativa che ho incontrato nell'usare le variabili Session è che ti grava sull'onere di tenerne traccia, accertarti che siano popolate di dati relavent e di eliminarle.

Non è quello che facciamo quando stiamo programmando in qualche modo?

— Mac
fonte

1

Pensavo come il tuo collega a causa di alcune brutte esperienze che avevo avuto problemi di debug relativi alle variabili di sessione, che erano davvero solo incompetenza da parte mia. Sì, puoi cavartela in una certa misura senza variabili di sessione, usando stringhe di query, campi nascosti nei moduli e altre cose. Tuttavia diventa molto complicato farlo in questo modo se l'applicazione ha qualcosa al di là del flusso logico più elementare per determinare lo stato. Esiste anche il rischio per la sicurezza di mostrare il funzionamento interno dell'applicazione tramite stringhe di query e campi nascosti, ognuno dei quali può fungere da vettori di attacco.

Quando si lavora con le variabili di sessione, è sufficiente tenere traccia di quando vengono impostati e non impostati, poiché ciò determinerà il flusso logico dell'applicazione. È come la gestione della memoria in un linguaggio come C.

Si noti che questo è solo dalla mia esperienza di lavoro con PHP su un progetto relativamente piccolo senza framework, le cose potrebbero essere diverse su altre piattaforme ma penso che il principio generale sia ancora valido.

— primehunter326
fonte

2

Come si ottengono le semantiche con più schede quando si utilizzano le sessioni per lo stato coinvolto nel flusso di controllo? Le sessioni funzionano bene per il login e le impostazioni come le proprietà, ma non hanno la semantica giusta per la maggior parte degli altri usi.

— CodesInChaos,

Non sono sicuro, ciò che ho pubblicato si basava sulla mia esperienza dichiaratamente limitata nella creazione di un'app Web basata su database in PHP / MySQL. Come vengono generalmente gestite più schede nei browser (suppongo sia quello a cui ti riferisci)?

— primehunter326,

@ primehunter326 Con parametri di instradamento o stringhe di query o campi modulo nascosti.

— Casey,

0

Come affermato in precedenza, HTTP è Stateless e Session Variable. La progettazione HTTP per essere senza stato aiuta la memorizzazione nella cache delle risorse. Per risorse disponibili pubblicamente.

È possibile progettare un sito Web senza variabile di sessione, ma è più difficile. Il più difficile (IMHO) è il login / logout di fantasia, gli schemi di autenticazione HTTP non forniscono gli strumenti necessari per l'autenticazione tramite un modulo HTML (potresti hackerare qualcosa con javascript - XHR su https: // untel: passowrd@mydomain.com ) e è ancora più difficile disconnettersi ed essere compatibile con più browser. si è discusso delle liste di willing su questo, ma se ricordo bene l'idea è stata abbandonata.

Per il resto, dovresti essere in grado di vivere senza variabili di sessione. Avrai un certo stato su un database, file o ovunque ma l'uso per le variabili di sessione dovrebbe essere raro.

Se il tuo utente ha un carrello, è una sessione variabile solo se si suppone che l'utente sia in grado di navigare su due computer / browser senza condividere il carrello.

— Mathieu
fonte