2010-10-16 9 views
8

Utilizzo Flask da un po 'di tempo e mi sto davvero godendo il framework. Una cosa che non riesco a capire è che in quasi tutti gli altri luoghi si parla di memorizzare la sessione sul server e l'id di sessione sul client, che quindi identificherebbe la sessione. Tuttavia, dopo aver usato il pallone, non sento il bisogno di farlo. Salvare la sessione come cookie sul client serve crittograficamente il mio scopo e sembra anche abbastanza sicuro. L'unica cosa che l'essere non sono in grado di cifrare le chiavi di sessione per esempio:Perché memorizzare le sessioni sul server anziché all'interno di un cookie?

session['life'] = 'the great one' 

apparirebbe come

life='gfhjfkjdfa some encryption kj' 

nel cookie salvati sul client. Ma come sarebbe importato in quanto è ancora crittografato. Sono sicuro che le persone qui conoscono le cose molto meglio di me, quindi chiedi a qualcuno di chiarire :-)

risposta

14

Anche se i dati vengono crittografati, l'utente potrebbe ancora rotolare indietro il loro biscotto a uno stato precedente (a meno che non si avvia la codifica di una volta gli ID ecc)

esempio cookie dice che l'utente ha 100 crediti, l'utente spende 100 crediti, ottengono un nuovo cookie dicendo che hanno 0 crediti. Potrebbero quindi ripristinare il loro cookie precedente (con 100 crediti).

In base alla modalità di crittografia del cookie, l'utente può anche essere in grado di eliminare le chiavi, inserire dati falsi, ecc.

+0

Grazie Nick! Ma ancora una volta la crittografia non si prenderà cura di esso.per ad esempio sessione [credits ] = 100 verrebbe salvato come qualcosa come crediti = 'agfkalh un po' di crittografia agakh '. E se la chiave segreta utilizzata per crittografare il cookie è sconosciuta all'utente ed è abbastanza difficile, come sarebbe in grado di causare qualsiasi cambiamento. può sicuramente andare avanti cancellando le chiavi e inserendo alcuni dati fasulli ma finché non è in grado di decifrare il cookie, come potrebbe essere creato qualsiasi problema – Rasmus

+6

Se 100 crediti sono crittografati come crediti = "abc", l'utente può vedere questo, e sa che "abc" sarà decrittografato a 100. Non devono essere in grado di decifrare loro stessi. Così possono spendere tutti i crediti, quindi impostare nuovamente i crediti su "abc" Ci sono modi per prevenire questo , ma non vale davvero la pena quando puoi semplicemente archiviare i dati sul server. – Nick

+0

Grazie! .. quello era qualcosa che stavo cercando in realtà, semplicemente non mi è venuto in mente .. – Rasmus

7

Se i dati di sessione sono necessari sul server, ha senso archiviarli sul server. Mantiene giù la massa di dati inviati avanti e indietro dal client. Inoltre, i cookie hanno un limite alla quantità di dati che possono memorizzare.

+0

+1 per un sommario bello e conciso. –

+0

Grazie Ned! ma nella maggior parte dei casi non sarà irrilevante il volume dei dati. – Rasmus

+2

Ma sì, +1 perché ritengo che questo sia un motivo valido che immagino di poter tranquillamente ignorare nella mia app :-). Tuttavia, ancora in attesa di ulteriori risposte a questo! – Rasmus

6

Oltre ai punti già citati

  1. Gli utenti possono disabilitare i cookie utilizzando le impostazioni del browser. Anche molti scanner antivirus scansionano e contrassegnano i cookie come rischi, a causa dei quali anche i cookie potrebbero non essere consentiti sul computer degli utenti.

  2. I cookie possono essere cancellati dall'utente anche nel mezzo della sua sessione. (In effetti, l'ho fatto inavvertitamente l'altro giorno quando uno dei miei PC ha scansionato i cookie di tracciamento elencati ... e ho appena cliccato su "Clean" e sono andati tutti via). Nel caso in cui l'utente dovesse cancellare i cookie, lo stato dell'utente andrà perso.

Se si utilizzano i cookie per gestire l'intero stato, si dipende sempre dall'ambiente client e dalle relative impostazioni. In quanto tale, probabilmente avrai bisogno di un meccanismo di ripiego nel caso in cui i cookie vengano cancellati/disabilitati ecc. Affinché la tua applicazione funzioni correttamente.

+0

Grazie InSane per aver risposto, ma non era quello che volevo sapere :-). Quello che volevo sapere era perché memorizzare i dati relativi alle sessioni sul server. Voglio dire, anche se memorizzi le variabili di sessione sul server, dovresti memorizzare l'ID di sessione sul client in un cookie. Per rispondere a ciò che hai detto, eliminando i cookie, l'utente effettivamente fa più male a se stesso mentre perde il sessione. Potrebbe essere effettivamente disconnesso se è connesso al sito, o potrebbe addirittura perdere alcuni dati. Per quanto riguarda la disattivazione dei cookie, suppongo che il fallback debba essere elaborato. Grazie – Rasmus

+1

@Alice - In realtà questo era il punto che stavo cercando di fare. Fondamentalmente, è necessario memorizzare i dati relativi alle sessioni sul server perché l'archiviazione sul client non è affidabile a causa degli esempi sopra indicati. Quando i cookie sono disabilitati, il sessionid viene solitamente passato in una querystring come il suo unico valore. Le sessioni possono essere rese indipendenti dai cookie - anche per l'ID di sessione – InSane

+0

"il sessionid viene solitamente passato in una querystring come il suo unico valore" -Sì che suona bene..1 su ... Grazie – Rasmus

1

Il contenitore di implementazione SecureCookie utilizza non crittografa i valori. L'unica cosa che viene assicurata è che l'utente non può modificare il cookie senza conoscere il segreto utilizzato dall'applicazione.

Problemi correlati