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

Question

.

CHIUSO . Questa domanda è basata sull'opinione . Attualmente non accetta risposte.

---

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che possa essere risolta con fatti e citazioni di Modifica di questo post .

chiuso 2 anni fa .

Migliora questa domanda .

Perché non salviamo le informazioni sui cookie dei visitatori del sito Web (abbonati) nel database piuttosto che impostare un file sulla macchina dell'utente. Sì, so che potrei sembrare sciocco per i seguenti motivi:

.

1. Manutenzione delle informazioni del database per ogni singolo utente per il "blocco di dati" di dati è difficile.

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

3. Le richieste continue devono essere apportate al server Web per ciascuna e ogni piccola informazione.

Il mio punto è, se memorizzeremo i dati dell'utente in un database piuttosto che in un file sulla macchina del client, possiamo fornire sicurezza al cliente non permettendo ad altre organizzazioni o altri siti (o anche gli hacker) a Accedi alle informazioni dell'utente dai cookie.

Inoltre, possiamo monitorare 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 continuamente, non è, grazie ad Ajax. Ciò fornisce un po 'di supporto alla mia posizione: l'invio di richieste a un server Web reso così semplice utilizzando Ajax.

Allora, è una buona idea memorizzare le informazioni sensibili dell'utente in un database piuttosto che impostare un file piccolo sulla macchina dell'utente?

Per essere specifico, non sto parlando di sessioni!

Answer 1

Il tuo approccio è decisamente valido ma ha un problema fondamentale (che è probabilmente il motivo del motivo per cui i cookie sono stati creati in primo luogo): Identificazione.

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

Informazioni generalmente, sensibili non sono pensate per essere memorizzate nei cookie.Tali informazioni sono al meglio memorizzate sul lato server (come indicato).

Answer 2

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

Cosa fai bisogno sulla macchina del cliente è un piccolo cookie contenente un riferimento oscuro e dura da indovinare a questi dati sensibili.

Congratulazioni!Hai appena reinventato sessioni!

(IServers possono essere impostati per memorizzare i dati di sessione in un database anziché in file piatti sul server se lo si preferisce in questo modo.)

Answer 3

È vero che la saggezza convenzionale è quella di evitare di utilizzare i cookie per i dati sensibili perché sono memorizzati sul client e un hacker può stringere con loro e possibilmente fare danni.Tuttavia, c'è una ragione convincente per cui i cookie potrebbero valere una seconda occhiata: scalabilità.È difficile avere un pool di dati di sessione di alta performance disponibile per un numero arbitrario di server cloud:

http://aws.typepad.com/aws/2012/04/Scalable-Sessione-Handling-in-php-using-amazon-dynamodb.html

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

http://www.cse.msu.edu/~Alexliu / Pubblicazioni / Cookie / Cookie.pdf

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

Answer 4

Generally we use cookies because we're not necessarily setting any sensitive data in them. If your application does has sensitive data that you don't want anybody fiddling with then by all means use every server-side and DB tool at your disposal to solve that, but not all applications and implementations need that level of security in these respects. Setting cookies is for convenience, that's all.

Answer 5

This is done already, or we'd be storing user names, addresses, and credit card information in a cookie rather than on the database. You have to evaluate what makes sense to keep in the database vs. what makes sense to store as a cookie. Server performance, bandwidth, scalability - all of these have to be kept in mind. Remember that the more we store server side, the more we'll have to deliver client-side.

You also mention sessions - sessions are cookies (kinda).

Answer 6

I came across this post whilst looking for some similar advice related to the cookie vs database argument.

Say, I have some user data in the form of integer lists, i.e. some bookmarked products, a max of 80 per user.

In the database, this could transpose to say 4 tables (1 for each data type), so that's 20 rows per user.

If you had a million unique visitors per annum and for arguments sake 70% were guest users as opposed to members, then this could add 14m rows to a table, which otherwise might be just 6m rows. Of course you could have a cull policy for guest users, but that becomes awkward to manage accurately - whats to say a user doesn't return after 9 months to find his/her data wiped.

The other side of the coin is that guest data is stored in cookies, so it doesn't matter how long its stored. I appreciate that more work is involved managing two storage methods but thats the only downside I can think of.

Anyone got any views on this, as I'd appreciate some advice.