Cosa sono le sessioni? Come funzionano?


332

Sto appena iniziando a imparare lo sviluppo di applicazioni Web, usando Python. Mi sto imbattendo nei termini "cookie" e "sessioni". Comprendo i cookie in quanto memorizzano alcune informazioni in una coppia chiave-valore sul browser. Ma ho un po 'di confusione riguardo alle sessioni, anche in una sessione archiviamo i dati in un cookie sul browser dell'utente.

Ad esempio: accedo usando username='rasmus'e password='default'. In tal caso, i dati verranno inviati al server che dovrebbe controllare e accedere se autenticato. Tuttavia durante l'intero processo il server genera anche un ID di sessione che verrà memorizzato in un cookie sul mio browser. Ora il server memorizza anche questo ID sessione nel suo file system o archivio dati.

Ma basandomi solo sull'ID sessione, come sarebbe in grado di conoscere il mio nome utente durante il mio successivo attraversamento del sito? Memorizza i dati sul server come un dict in cui la chiave sarebbe un ID di sessione e dettagli come username, emailecc. Sarebbero i valori?

Sto diventando piuttosto confuso qui. Ho bisogno di aiuto.


9
"Memorizza i dati sul server come un dict in cui la chiave sarebbe un ID di sessione e dettagli come nome utente, e-mail ecc. Sarebbero i valori?" ...sì. Il 'dict' potrebbe essere un database relazionale, ma sostanzialmente è così che funziona.
bobince,

14
Volevo capire anche le sessioni web, ora capisco. Ho finito per scrivere la mia wiki se questo mi fosse di aiuto: machinesaredigging.com/2013/10/29/how-does-a-web-session-work
eloone

Nel caso in cui non lo sapessi: la memorizzazione della password sul lato client non è sicura, anche se la password è sottoposta a hash (in realtà non fa differenza. Il cracker può inserire direttamente la password con hash creando un cookie falso) sono modi migliori per memorizzare lo stato di accesso.
cytsunny,

1
Ho scritto il mio usando i dettagli del livello di protocollo - bitspedia.com/2012/05/…
Asif Shahzad

Risposte:


400

Poiché HTTP è senza stato, al fine di associare una richiesta a qualsiasi altra richiesta, è necessario un modo per archiviare i dati utente tra richieste HTTP.

I cookie o i parametri URL (ad es. Come http://example.com/myPage?asd=lol&boo=no ) sono entrambi modi adatti per trasportare dati tra 2 o più richieste. Tuttavia, non sono utili nel caso in cui non si desideri che i dati siano leggibili / modificabili sul lato client.

La soluzione è quella di archiviare quel lato del server di dati, dargli un "id" e far sapere al client (e restituirlo ad ogni richiesta http) quell'id. Ecco fatto, sessioni implementate. Oppure puoi utilizzare il client come comodo archivio remoto, ma crittograferesti i dati e manterrai il lato server segreto.

Naturalmente ci sono altri aspetti da considerare, come se non volessi che le persone dirottassero le sessioni degli altri, che le sessioni non durassero per sempre ma scadessero, e così via.

Nel tuo esempio specifico, l'id utente (potrebbe essere un nome utente o un altro ID univoco nel database degli utenti) viene archiviato nei dati della sessione, sul lato server, dopo un'identificazione corretta. Quindi, per ogni richiesta HTTP che ricevi dal client, l'id di sessione (fornito dal client) ti indicherà i dati di sessione corretti (memorizzati dal server) che contiene l'id utente autenticato - in questo modo il tuo codice saprà quale utente sta parlando.


3
"non si desidera che tali dati vengano mantenuti lato client". Perchè no? Se si utilizza una crittografia avanzata, è possibile consentire al client di mantenere i dati della sessione crittografati e archiviati in un cookie. Ciò semplifica notevolmente il ridimensionamento su più nodi poiché i server non devono "ricordare" nulla.
Matt Harrison,

5
@MattHarrison come decifreresti i dati senza "ricordare nulla" sul lato server? Ho comunque cercato di espandere questo argomento nella mia risposta.
Luke404,

2
@MattHarrison tieni presente che la memorizzazione di molti dati lato utente aumenterà il tuo traffico.
nitsas,

5
Una terza parte non sarebbe in grado di agire come utente se fosse in grado di intercettare la chiave di sessione dell'utente? Supponendo che il sito non usi HTTPS, sembra che una terza parte possa mascherarsi da utente con una chiave di sessione anche se la chiave è crittografata. Il server lo decifrerebbe e basta.
user137717

2
@ user137717 sì, questa è una possibilità se si consente l'accesso alla sessione letteralmente a "ognuno che presenta l'id di sessione corretto". Esistono diverse restrizioni che puoi mettere in atto, una delle più semplici e le più comuni è quella di memorizzare l'IP del client nella sessione: se un client di un altro IP presenta lo stesso ID di sessione, lo contrassegni come forgiato ed elimina la sessione.
Luke404,

110

Spiegazione semplice per analogia

Immagina di essere in una banca, cercando di ottenere dei soldi dal tuo conto. Ma è buio; la banca è nera come la pece: non c'è luce e non puoi vedere la tua mano davanti al tuo viso. Sei circondato da altre 20 persone. Hanno tutti lo stesso aspetto. E tutti hanno la stessa voce. E tutti sono un potenziale cattivo. In altre parole, HTTP è apolide.

Questa banca è un tipo divertente di banca - per amor di discussione ecco come funzionano le cose:

  1. aspetti in linea (o online) e parli con il cassiere: fai una richiesta di prelievo di denaro, e poi
  2. devi aspettare brevemente sul divano e 20 minuti dopo
  3. devi andare e raccogliere effettivamente i tuoi soldi dal cassiere.

Ma come ti dirà il cassiere a parte gli altri?

Il cassiere non può vederti o riconoscerti facilmente, ricorda, perché le luci sono tutte spente. E se il tuo cassiere concede il tuo prelievo di $ 10.000 a qualcun altro - la persona sbagliata ?! È assolutamente vitale che il cassiere ti riconosca come colui che ha effettuato il prelievo, in modo da poter ottenere il denaro (o la risorsa) che hai richiesto.

Soluzione:

Quando appari per la prima volta al cassiere, lui o lei ti dice qualcosa in segreto:

"Ogni volta che parli con me", dice il cassiere, "dovresti prima identificarti come GNASHEU329 - in questo modo so che sei tu".

Nessun altro conosce il passcode segreto.

Esempio di come ho prelevato contanti:

Quindi decido di andare a rilassarmi per 20 minuti e poi vado dal cassiere e dico "Vorrei riscuotere il mio prelievo"

Il cassiere mi chiede: "chi sei ??!"

"Sono io, signor George Banks!"

"Provalo!"

E poi dico loro il mio passcode: GNASHEU329

"Certamente Mr Banks!"

Fondamentalmente è così che funziona una sessione. Permette di essere identificati in modo univoco in un mare di milioni di persone. Devi identificarti ogni volta che hai a che fare con il cassiere.

Se hai domande o non sei chiaro, ti preghiamo di inviare un commento e proverò a chiarirlo per te.

Spiegazione tramite immagini:

Sessioni spiegate tramite immagine


9
Adoro questa spiegazione: nella tua analogia, come impediresti ad altre persone di intercettare e anche ascoltare il passcode segreto che ti dice il cassiere? In altre parole, se il session_id viene rubato, non sarebbe possibile per qualcuno imitare le tue credenziali?
Passeggiata

Il dirottamento della sessione @wmock è sicuramente un problema: dai un'occhiata! owasp.org/index.php/Session_hijacking_attack
BKSpurgeon

2
bellissimo esempio !! deve essere condiviso con menti ansiose in cerca di apprendimento!
Victor,

nella tua analogia, GNASHEU329è la password dell'utente, che genera un token di autenticazione che scade fino a un certo momento; Il signor Banks può quindi utilizzare il token di autenticazione per effettuare diversi prelievi successivi senza dover fornire ripetutamente la password al cassiere?
Daniel Lizik,

@DanielLizik sei def. capire il concetto! Ma non sono abbastanza informato sui flussi di lavoro basati su token per darti una risposta intelligente. Il principio generale è che il server deve essere in grado di identificare in qualche modo chi è la persona che effettua la richiesta.
BKSpurgeon,

39

"Sessione" è il termine utilizzato per fare riferimento al tempo di un utente che naviga in un sito Web. Ha lo scopo di rappresentare il tempo tra il loro primo arrivo in una pagina del sito fino al momento in cui smettono di utilizzare il sito. In pratica, è impossibile sapere quando l'utente ha finito con il sito. Nella maggior parte dei server c'è un timeout che termina automaticamente una sessione a meno che non sia richiesta un'altra pagina dallo stesso utente.

La prima volta che un utente connette un tipo di ID sessione viene creato (il modo in cui viene eseguito dipende dal software del server Web e dal tipo di autenticazione / accesso in uso sul sito). Come i cookie, di solito questo non viene più inviato nell'URL perché è un problema di sicurezza. Invece viene memorizzato insieme a un sacco di altre cose che collettivamente vengono anche chiamate sessioni. Le variabili di sessione sono come i cookie - sono coppie nome-valore inviate insieme a una richiesta per una pagina e restituite con la pagina dal server - ma i loro nomi sono definiti in uno standard web.

Alcune variabili di sessione vengono passate come intestazioni HTTP . Sono passati avanti e indietro dietro le quinte di ogni pagina sfogliata in modo da non apparire nel browser e dire a tutti qualcosa che potrebbe essere privato. Tra questi ci sono USER_AGENT, o tipo di browser che richiede la pagina, il REFERRER o la pagina collegata alla pagina richiesta, ecc. Alcuni software per server Web aggiungono le proprie intestazioni o trasferiscono dati di sessione aggiuntivi specifici al software del server. Ma quelli standard sono abbastanza ben documentati.

Spero che aiuti.


So che sui server IIS che utilizzo posso ottenere il nome utente da un'intestazione USER_NAME, ma potrebbe essere specifico per IIS.
Tim Rourke,

Cosa significa qui il REFERRER?
Gab 是 好人

@Gab 是 好人 REFERRER generalmente indica una stringa arbitraria che il client invia nell'intestazione della richiesta HTTP "Referer". Esso deve contenere l'URL della risorsa che, si sa, di cui il cliente alla risorsa corrente.
Luke404,

Grazie, dovrebbe , quindi non necessariamente. quindi penso che la gente usi spesso questa intestazione con semantica diversa da quella suggerita nella RFC, giusto?
Gab 是 好人

Prima hai scritto Like cookies, this usually doesn't get sent in the URL anymoree poi Session variables are like cookies - they're name-value pairs sent along with a request for a page. Cosa succede esattamente? Viene inviato con la successiva richiesta?
KPMG,

19

HTTP è un protocollo di connessione stateless, ovvero il server non è in grado di distinguere tra connessioni diverse di utenti diversi.

Da qui deriva il cookie, una volta che un client si connette per la prima volta a un server, il server genera un nuovo ID di sessione, che verrà successivamente inviato al client come valore del cookie. E d'ora in poi, questo id di sessione identificherà quella connessione client, perché all'interno di ogni richiesta HTTP vedrà l'id di sessione appropriato all'interno dei cookie.

Ora per ogni ID sessione, il server mantiene una struttura di dati, che gli consente di archiviare dati specifici dell'utente, questa struttura di dati che puoi chiamare in modo astratto sessione.


1
Puoi chiarire meglio questo aspetto: "Ora per ogni ID di sessione, il server mantiene una struttura di dati, che gli consente di memorizzare dati specifici dell'utente, questa struttura di dati che puoi chiamare in modo astratto sessione". Quali informazioni specifiche sul client memorizza il server?
realPK,

Puoi chiarire meglio questo aspetto: "Ora per ogni ID di sessione, il server mantiene una struttura di dati, che gli consente di memorizzare dati specifici dell'utente, questa struttura di dati che puoi chiamare in modo astratto sessione". Quali informazioni specifiche sul client memorizza il server?
Gab 是 好人

Stessa domanda di cui sopra, sarebbe utile in caso di risposta.
Suraj Jain,

4

Pensa a HTTP come a una persona (A) che ha PERDITA DI MEMORIA A BREVE TERMINE e dimentica ogni persona non appena quella persona scompare.

Ora, per ricordare persone diverse, A scatta una foto di quella persona e la conserva. La foto di ogni persona ha un numero ID. Quando quella persona torna di nuovo in vista, quella persona dice il suo numero ID ad A e A trova la sua foto per numero ID. E voilà !!, A sa chi è quella persona.

Lo stesso è con HTTP. Soffre di PERDITA DI MEMORIA A BREVE TERMINE. Utilizza Sessioni per registrare tutto ciò che hai fatto durante l'utilizzo di un sito Web, quindi, quando torni, ti identifica con l'aiuto dei cookie (i cookie sono come un token). L'immagine è la sessione qui e ID è il cookie qui.

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.