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:
Maintenance des informations de base de données pour chaque utilisateur pour toujours petit "morceau" de données est difficile.
Il peut être difficile de récupérer des données lorsque le serveur de base de données est en panne.
Les demandes continues 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'autoriser 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 estimez 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-il 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!
6 Réponses :
Les informations sensibles ne devraient 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.)
Généralement, nous utilisons des cookies car nous ne définissons pas nécessairement de données sensibles. Si votre candidature a des données sensibles que vous ne voulez que vous ne voulez que personne avec tous les moyens, utilisez chaque outil côté serveur et DB à votre disposition pour résoudre ce problème, mais pas toutes les applications et les implémentations n'ont besoin de ce niveau de sécurité à cet égard. Cadrage des cookies est pour une commodité, c'est tout.
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 vs. 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 censées être stockées dans des cookies. Ces informations sont mieux stockées sur le côté serveur (comme vous l'avez indiqué).
Ceci est déjà fait, sinon nous serions stockés des noms d'utilisateur, des adresses et des informations de carte de crédit dans un cookie plutôt que sur la base de données. Vous devez évaluer ce qui est logique de garder dans la base de données contre ce qui est logique de stocker comme un cookie. Performance du serveur, bande passante, évolutivité - Tout cela doit être gardé à l'esprit. N'oubliez pas que plus nous stockons le serveur, plus nous devrons livrer le côté client.
Vous mentionnez également des sessions - sessions sont cookies (un peu).
J'ai rencontré cet article tout en cherchant des conseils similaires liés à l'argument de la base de données Cookie VS.
Dites, j'ai des données utilisateur sous forme de listes entière, c'est-à-dire des produits bookmarchés, un maximum de 80 par utilisateur.
Dans la base de données, cela pourrait transposer à 4 tables (1 pour chaque type de données), de sorte que 20 lignes par utilisateur.
Si vous aviez un million de visiteurs uniques par an et que des arguments à partir de 70% étaient des utilisateurs invités par opposition aux membres, cela pourrait alors ajouter des rangées de 14 m à une table, ce qui pourrait ne représenter que 6 millions de lignes. Bien sûr, vous pourriez avoir une politique de CULL pour les utilisateurs invités, mais cela devient gênant de gérer avec précision - ce qu'il faut dire qu'un utilisateur ne revient pas après 9 mois pour trouver ses données essuyées.
L'autre côté de la pièce de monnaie est que les données invitées sont stockées dans des cookies, de sorte que cela n'a pas d'importance que cela soit stocké. J'apprécie que plus de travail est impliqué de gérer deux méthodes de stockage, mais c'est le seul inconvénient que je puisse penser.
Quelqu'un a eu des points de vue à ce sujet, comme j'apprécierais des conseils.
Il est vrai que la sagesse conventionnelle consiste à éviter d'utiliser des cookies pour des données sensibles, car ils sont stockés sur le client et un pirate informatique peut bricoler avec eux et éventuellement des dégâts. 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 d'avoir un bassin de données de session très performant disponible pour 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 en détail sur la manière dont un système de cookie sécurisé pourrait être construit:
http://www.cse.msu.edu/~ AlexLiu / Publications / Cookie / Cookie.PDF
Donc, ce serait peut-être que ce qui est vieux est nouveau à nouveau.