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.

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.

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:

"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.

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.

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.