Est-il préférable de stocker des données utilisateur dans une base de données plutôt que dans les cookies?[fermé]

Question

fermé . Cette question est basée sur les opinions . Il n'accepte pas actuellement les réponses.

---

Voulez-vous améliorer cette question? Mettre à jour la question afin qu'elle puisse être répondue avec des faits et des citations de Modification de ce message .

FERMÉ Il y a 2 ans .

.

Améliorer cette question

Pourquoi ne sauvons pas les informations de cookie des visiteurs de site Web (abonnés) dans la base de données plutôt que de définir un fichier sur la machine de l'utilisateur. Oui, je sais que je pourrais sembler idiot pour les raisons suivantes:

1. Maintenance des informations de base de données pour chaque utilisateur pour tout petit "morceau" de données est difficile.

2. Il peut être difficile de récupérer des données lorsque le serveur de base de données est en panne.

3. Les demandes en continu doivent être apportées au serveur Web pour chaque petite information.

Mon point est que si nous allons stocker les données de l'utilisateur dans une base de données plutôt que dans un fichier sur la machine du client, nous pouvons fournir une sécurité au client en ne permettant pas d'autres organisations ou d'autres sites (ni même pirates) de Accédez aux informations de l'utilisateur des cookies.

En outre, nous pouvons suivre les activités ou le comportement de l'utilisateur. (Je veux dire, nous ne savons réellement que ce que l'utilisateur fait (activité côté client) comme une altération des données.)

Si vous pensez qu'il pourrait être difficile d'envoyer des demandes au serveur Web en permanence, ce n'est pas le cas, grâce à Ajax. Cela donne un soutien à ma position: Envoi de demandes à un serveur Web rendu si simple à l'aide d'Ajax.

Alors, est-ce une bonne idée de stocker les informations sensibles de l'utilisateur dans une base de données plutôt que de définir un petit fichier sur la machine de l'utilisateur?

Pour être précis, je ne parle pas de sessions!

Answer 1

Votre approche est définitivement valide mais a un problème fondamental (qui est probablement la raison pour laquelle les cookies ont été créés en premier lieu): identification.

Comment pouvez-vous identifier l'utilisateur A contre l'utilisateur B sans demander un nom d'utilisateur / mot de passe?Les cookies offrent un moyen simple de faire cette différenciation.Une fois que l'utilisateur est identifié, vos points deviennent complètement valides.

généralement, des informations sensibles ne sont pas destinées à être stockées dans des cookies.Ces informations sont mieux stockées sur le côté serveur (comme indiqué).

Answer 2

Les informations sensibles ne doivent pas être dans un cookie, je suis d'accord avec vous là-bas.Il doit être stocké quelque part sur le côté serveur, soit dans un fichier plat sur le serveur lui-même, soit dans une base de données.

Ce que vous avez besoin sur la machine client est un petit cookie contenant une référence obscure et difficile à deviner à ces données sensibles.

Félicitations!Vous venez de réinventer des sessions!

(WebServers peut être configuré pour stocker des données de session dans une base de données au lieu de fichiers plats sur le serveur si vous le préférez de cette façon.)

Answer 3

Il est vrai que la sagesse conventionnelle consiste à éviter d'utiliser des cookies pour des données sensibles car elles sont stockées sur le client et un pirate informatique peut bricoler avec eux et éventuellement endommager.Cependant, il y a une raison impérieuse pour la raison pour laquelle les cookies pourraient valoir un deuxième regard: évolutivité.Il est difficile de disposer d'un pool de données de session très performant à la disposition d'un nombre arbitraire de serveurs de cloud:

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

Voici un lien que j'ai trouvé qui passe très en détail sur la construction d'un système de cookie sécurisé:

http://www.cse.msu.edu/~AlexLiu / Publications / Cookie / Cookie.PDF

Donc, ce serait peut-être que ce qui est vieux est nouveau à nouveau.

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.