¿Es mejor almacenar datos de usuario en una base de datos en lugar de en cookies?[cerrado]

Question

cerrado . Esta pregunta es basada en opinión . Actualmente no está aceptando respuestas.

---

¿Quieres mejorar esta pregunta? Actualizar la pregunta para que pueda responderse con hechos y citas de Edición de este post .

cerrado hace 2 años .

Mejorar esta pregunta

¿Por qué no guardamos la información de cookies de los visitantes del sitio web (suscriptores) en la base de datos en lugar de configurar un archivo en la máquina del usuario. Sí, sé que podría parecer tonto por las siguientes razones:

1. Mantener la información de la base de datos para cada usuario de un solo usuario para siempre 'trozo' de datos es difícil.

2. Puede ser difícil recuperar datos cuando el servidor de la base de datos está abajo.

3. Se deben realizar solicitudes continuas en el servidor web para cada pequeña información.

Mi punto es, si vamos a almacenar los datos del usuario en una base de datos en lugar de en un archivo en la máquina del cliente, podemos proporcionar seguridad al cliente al no permitir que otras organizaciones u otros sitios (o incluso hackers) Acceda a la información del usuario desde las cookies.

Además, podemos rastrear las actividades o el comportamiento del usuario. (Quiero decir, en realidad no sabemos lo que el usuario está haciendo (actividad del lado del cliente) como manipulación de datos).

Si cree que puede ser difícil enviar solicitudes al servidor web continuamente, no lo es, gracias a AJAX. Esto le da algún apoyo a mi posición: enviar solicitudes a un servidor web hecho tan simple usando AJAX.

Entonces, ¿es una buena idea almacenar la información confidencial del usuario en una base de datos en lugar de establecer un archivo pequeño en la máquina del usuario?

para ser específico, ¡no estoy hablando de sesiones!

Answer 1

Su enfoque es definitivamente válido, pero tiene un problema fundamental (que es probablemente la razón por la cual se crearon las cookies en primer lugar): Identificación.

¿Cómo puede identificar al usuario a vs. usuario b sin pedir un nombre de usuario / contraseña?Las cookies proporcionan una manera fácil de hacer esta diferenciación.Una vez que se identifica el usuario, sus puntos se vuelven completamente válidos.

En general, la información confidencial no está destinada a almacenarse en las cookies.Dicha información se almacena mejor en el lado del servidor (como lo indicó).

Answer 2

La información confidencial no debería estar en una cookie, estaré de acuerdo con usted allí.Debe almacenarse en algún lugar del lado del servidor, ya sea en un archivo plano en el propio servidor, o en una base de datos.

Lo que necesita en la máquina cliente es una pequeña cookie que contiene algunas referencias ocultas y difíciles de adivinar a estos datos confidenciales.

¡Felicidades!¡Acabas de reinventar las sesiones!

(los servidores web pueden configurarse para almacenar datos de sesión en una base de datos en lugar de en archivos planos en el servidor si lo prefiere de esa manera).

Answer 3

Es cierto que la sabiduría convencional es evitar el uso de cookies para datos confidenciales porque se almacenan en el cliente y un pirata informático puede jugar con ellos y posiblemente hacer daños.Sin embargo, hay una razón convincente por la que las cookies podrían valer una segunda apariencia: escalabilidad.Es difícil tener un grupo de datos de sesión de alto rendimiento disponible para un número arbitrario de servidores en la nube:

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

Aquí hay un enlace que encontré, que tiene un gran detalle sobre cómo se podría construir un sistema seguro de cookies:

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

Por lo tanto, podría ser que lo que es viejo es nuevo otra vez.

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.