È meglio memorizzare i dati dell'utente in un database piuttosto che nei cookie?

Question

Perché non salviamo le informazioni sui cookie dei visitatori del sito web (iscritti) nel database anziché impostare un file sul computer dell'utente. Sì, lo so che potrei sembrare stupido per i seguenti motivi:

1. Mantenere le informazioni del database per ogni singolo utente per sempre piccolo ‘pezzo’ di dati è difficile.

2. Potrebbe essere difficile recuperare i dati quando il server del database è inattivo.

3. Le richieste continue devono essere inoltrate al server Web per ogni piccola informazione.

Il mio punto è, se stiamo per archiviare i dati dell'utente in un database, piuttosto che in un file sulla macchina del cliente, siamo in grado di fornire sicurezza al cliente non permettendo altre organizzazioni o altri siti (o anche hacker) per accedere alle informazioni dell'utente dai cookie.

Inoltre, possiamo tracciare le attività o il comportamento dell'utente. (Voglio dire, in realtà non sappiamo cosa sta facendo l'utente (attività lato client) come la manomissione dei dati.)

Se ritieni che potrebbe essere difficile inviare richieste al server web in modo continuo, non è t, grazie ad Ajax. Ciò fornisce un certo supporto alla mia posizione: l'invio di richieste a un server Web reso così semplice con Ajax.

Quindi, è una buona idea memorizzare le informazioni sensibili dell'utente in un database piuttosto che impostare un file piccolo sul computer dell'utente?

Per essere precisi, non sto parlando di sessioni!

Answer 1

Il tuo approccio è sicuramente valido ma presenta un problema fondamentale (che è probabilmente la ragione per cui i cookie sono stati creati in primo luogo): identificazione.

Come si può identificare l'utente A con l'utente B senza chiedere nome utente/password? I cookie forniscono un modo semplice per fare questa differenziazione. Una volta identificato l'utente, i tuoi punti diventano completamente validi.

Generalmente, le informazioni sensibili non sono destinate ad essere memorizzate nei cookie.Tali informazioni sono memorizzate al meglio sul lato server (come indicato).

Answer 2

Le informazioni sensibili non devono essere in un cookie, sono d'accordo con te lì. Dovrebbe essere memorizzato da qualche parte sul lato server, in un file flat sul server stesso o in un database.

Quello che serve sul computer client è un piccolo cookie contenente un riferimento oscuro e difficile da indovinare per questi dati sensibili.

Congratulazioni! Hai appena reinventato le sessioni!

(web server può essere configurato per memorizzare i dati di sessione in un database anziché nel file flat sul server, se si preferisce in questo modo.)

Answer 3

Generalmente usiamo cookie perché non stiamo necessariamente impostare qualsiasi sensibili dati in loro. Se la tua applicazione ha dati sensibili che non vuoi manipolare con nessuno, allora usa tutti gli strumenti sul lato server e DB a tua disposizione per risolvere il problema, ma non tutte le applicazioni e le implementazioni richiedono quel livello di sicurezza sotto questi aspetti. L'impostazione dei cookie è per comodità, tutto qui.

Answer 4

Questo è già fatto, o dovremmo memorizzare i nomi utente, gli indirizzi e le informazioni della carta di credito in un cookie piuttosto che nel database. Devi valutare cosa ha senso tenere nel database e cosa ha senso archiviare come cookie. Prestazioni del server, larghezza di banda, scalabilità: tutti questi aspetti devono essere tenuti presenti. Ricorda che più conserviamo il lato server, più dovremo consegnare il lato client.

Si menzionano anche le sessioni - le sessioni sono i cookie (tipo).

Answer 5

Mi sono imbattuto in questo post mentre cercavo alcuni consigli simili relativi all'argomento cookie vs database.

Dire, ho alcuni dati utente sotto forma di elenchi di numeri interi, ad esempio alcuni prodotti con segnalibro, un massimo di 80 per utente.

Nel database, questo potrebbe trasporre dire 4 tabelle (1 per ogni tipo di dati), quindi 20 righe per utente.

Se si dispone di un milione di visitatori unici all'anno e il 70% degli argomenti era per gli utenti ospiti rispetto ai membri, questo potrebbe aggiungere 14 milioni di righe a una tabella, che altrimenti potrebbe essere solo 6 milioni di righe. Naturalmente si potrebbe avere una politica di eliminazione per gli utenti ospiti, ma ciò diventa difficile da gestire con precisione - cosa dire che un utente non ritorna dopo 9 mesi per trovare i suoi dati cancellati.

L'altro lato della medaglia è che i dati degli ospiti sono memorizzati nei cookie, quindi non importa per quanto tempo è memorizzato. Apprezzo il fatto che si lavori di più sulla gestione di due metodi di archiviazione, ma questo è l'unico svantaggio che riesco a pensare.

Chiunque ha qualche opinione su questo, come mi piacerebbe un consiglio.

Answer 6

È vero che la saggezza convenzionale consiste nell'evitare di utilizzare i cookie per dati sensibili perché sono memorizzati sul client e un hacker può armeggiare con loro e possibilmente fare danni. Tuttavia, esiste una ragione convincente per cui i cookie potrebbero valere un secondo aspetto: scalabilità. E 'difficile avere una piscina ad alte prestazioni dei dati di sessione a disposizione di un numero arbitrario di server cloud:

http://aws.typepad.com/aws/2012/04/scalable-session-handling-in-php-using-amazon-dynamodb.html

Ecco un link che ho trovato, che va in grande dettaglio su come un sistema di cookie sicuro potrebbe essere costruito:

http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf

Quindi potrebbe essere che ciò che è vecchio è nuovo nuovo.