3
votes

Devez-vous stocker les informations de connexion des utilisateurs dans la même base de données que votre site Web?

Fondamentalement, je souhaite créer un frontal HTML restreint pour présenter et modifier les champs d'une base de données. Les utilisateurs devront se connecter avec un nom d'utilisateur et un mot de passe pour y accéder. Stockeriez-vous les informations de connexion de l'utilisateur dans la même base de données mais dans une table séparée ou dans une base de données entièrement différente?


2 commentaires

Cela dépend du scénario. Pour les sites "standard", une table séparée dans une base de données de site suffit généralement.


De nombreux sites utilisent simplement une table dédiée pour les utilisateurs, certains sites utiliseront LDAP - il n'y a pas de réponse unique.


3 Réponses :


2
votes

Oui, je conserverais les informations de connexion dans la même base de données. C'est ainsi que la plupart des frameworks et par ex. CMS le fait. Puisqu'il doit y avoir une sorte de connexion à la base de données de connexion pour que la connexion fonctionne, les mêmes problèmes de sécurité s'appliqueraient à des bases de données séparées.


0 commentaires

5
votes

Je stocke les informations utilisateur dans la même base de données, je crée juste une table users qui stocke leur email de nom d'utilisateur et mot de passe haché. Assurez-vous de hacher et saler les mots de passe avant qu'ils ne soient insérés dans la base de données.


0 commentaires

0
votes

Une base de données de sécurité séparée peut être nécessaire lorsque plusieurs applications de base de données partagent le même modèle d'identification et d'autorisation. Lorsque vous développez une seule application, vous pouvez placer les données de sécurité dans la même base de données (cependant, vous pouvez utiliser un schéma séparé).

De plus, les détails de l'utilisateur et les informations de connexion sont généralement en relation 1: M, donc deux tables seront une solution plus flexible. C'est à dire. un utilisateur peut avoir le login / mot de passe interne ainsi que l'OpenID ou une autre identité externe.


0 commentaires