Dois-je utiliser le nom d'utilisateur ou l'ID de l'utilisateur pour référencer les utilisateurs authentifiés dans ASP.NET

Question

Ainsi, dans mon site Web d'apprentissage simple, j'utilise le système d'authentification ASP.NET intégré.

J'ajoute maintenant une table utilisateur pour enregistrer des éléments comme son zip, DOB etc.Ma question est:

1. Dans le nouveau tableau, la clé doit-elle être le nom d'utilisateur (la chaîne) ou l'ID utilisateur qui est le numéro de GUID qu'il utilise dans le asp_ tables.
2. Si la meilleure pratique consiste à utiliser ce vilain guide, est-ce que quelqu'un sait comment l'obtenir ?il ne semble pas être accessible aussi facilement que le nom (System.Web.HttpContext.Current.User.Identity.Name)
3. Si vous suggérez que je n'utilise ni l'un ni l'autre (ni les champs guid ni les champs userName fournis par l'authentification ASP.NET), comment puis-je le faire avec l'authentification ASP.NET ?Une option que j'aime est d'utiliser l'adresse e-mail de l'utilisateur comme connexion, mais comment faire pour que le système d'authentification ASP.NET utilise une adresse e-mail au lieu d'un nom d'utilisateur ?(ou il n'y a rien à faire là-bas, c'est juste moi qui décide que je "sais" que le nom d'utilisateur est en fait une adresse e-mail ?

Veuillez noter:

• Je ne demande pas comment obtenir un GUID dans .NET, je fais simplement référence à la colonne userID dans le asp_ tables comme guide.
• Le nom d'utilisateur est unique dans l'authentification ASP.NET.

Answer 1

Je suggérerais d'utiliser le nom d'utilisateur comme clé primaire dans le tableau si le nom d'utilisateur doit être unique, il y a quelques bonnes raisons de le faire :

1. La clé primaire sera un index clusterisé et ainsi la recherche des détails d'un utilisateur via son nom d'utilisateur sera très rapide.
2. Cela empêchera les noms d'utilisateur en double d'apparaître
3. Vous n'avez pas à vous soucier d'utiliser deux informations différentes (nom d'utilisateur ou guid)
4. Cela rendra l’écriture de code beaucoup plus facile car vous n’aurez pas à rechercher deux éléments d’information.

Answer 2

Vous devez utiliser un identifiant unique, soit le GUID que vous mentionnez, soit une autre clé générée automatiquement.Cependant, ce numéro ne doit jamais être visible par l'utilisateur.

Un énorme avantage est que tout votre code peut fonctionner sur l'ID utilisateur, mais le nom de l'utilisateur n'y est pas vraiment lié.Ensuite, l'utilisateur peut changer son nom (ce que j'ai trouvé utile sur les sites).Ceci est particulièrement utile si vous utilisez l'adresse e-mail comme identifiant de connexion de l'utilisateur...ce qui est très pratique pour les utilisateurs (ils n'ont alors pas besoin de se souvenir de 20 identifiants au cas où leur identifiant d'utilisateur commun serait populaire).

Answer 3

Vous devez utiliser l'ID utilisateur.Il s'agit de la propriété ProviderUserKey de MembershipUser.

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());

Answer 4

J'utiliserais un identifiant utilisateur.Si vous souhaitez utiliser un nom d'utilisateur, vous allez rendre la fonctionnalité "changer le nom d'utilisateur" très coûteuse.

Answer 5

Je suis d'accord avec Palmsey, bien qu'il semble y avoir une petite erreur dans son code:

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name)).ProviderUserKey.ToString());

devrait être

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());

Answer 6

Je dirais d'utiliser l'ID utilisateur afin que les noms d'utilisateur puissent toujours être modifiés sans affecter la clé primaire.Je définirais également la colonne du nom d'utilisateur pour qu'elle soit unique pour éviter les noms d'utilisateur en double.

Si vous recherchez principalement sur le nom d'utilisateur plutôt que sur l'ID utilisateur, faites du nom d'utilisateur un index clusterisé et définissez la clé primaire sur non clusterisée.Cela vous donnera l'accès le plus rapide lors de la recherche de noms d'utilisateur. Si toutefois vous recherchez principalement des ID utilisateur, laissez-le comme index clusterisé.

Modifier :Cela conviendra également mieux aux tables d'adhésion ASP.Net actuelles, car elles utilisent également l'ID utilisateur comme clé primaire.

Answer 7

C'est vieux mais je veux juste que les gens qui trouvent cela notent quelques choses :

1. La base de données des membres aspnet est optimisée pour accéder aux enregistrements des utilisateurs.La recherche d'index clusterisé (optimale) dans le serveur SQL est utilisée lorsqu'un enregistrement est recherché à l'aide d'un nom d'utilisateur et d'un identifiant d'application réduits.Cela a beaucoup de sens car nous ne disposons que du nom d'utilisateur fourni lorsque l'utilisateur envoie ses informations d'identification pour la première fois.

2. L'ID utilisateur guid donnera une taille d'index plus grande qu'un int mais cela n'est pas vraiment significatif car nous ne récupérons souvent qu'un seul enregistrement (utilisateur) à la fois et en termes de fragmentation, le nombre de lectures dépasse généralement largement le nombre d'écritures et de modifications. à une table d'utilisateurs - les gens ne mettent tout simplement pas à jour ces informations très souvent.

3. le script regsql qui crée les tables d'adhésion aspnet peut être modifié de sorte qu'au lieu d'utiliser NEWID comme valeur par défaut pour l'ID utilisateur, il puisse utiliser NEWSEQUENTIALID() qui offre de meilleures performances (j'ai profilé cela).

4. Profil.Quelqu'un qui crée un « nouveau site Web d'apprentissage » ne devrait pas essayer de réinventer la roue.L'un des sites Web pour lesquels j'ai travaillé utilisait une version prête à l'emploi des tables d'adhésion aspnet (à l'exclusion de l'horrible système de profil) et la table des utilisateurs contenait près de 2 millions d'enregistrements d'utilisateurs.Même avec un nombre aussi élevé d'enregistrements, les sélections étaient toujours rapides car, comme je l'ai dit au début, les index de la base de données se concentrent sur le nom d'utilisateur réduit + l'ID d'application pour effectuer une recherche d'index clusterisé pour ces enregistrements et, de manière générale, si SQL effectue une recherche d'index clusterisé pour trouver 1 enregistrement, vous n'avez aucun problème, même avec un grand nombre d'enregistrements, à condition de ne pas ajouter de colonnes aux tables et de commencer à extraire trop de données.

5. S'inquiéter d'un guide dans ce système, pour moi, sur la base des performances réelles et de l'expérience du système, est une optimisation prématurée.Si vous avez un int pour votre identifiant utilisateur mais que le système effectue des requêtes sous-optimales en raison de la conception de votre index personnalisé, etc.le système ne s'adaptera pas bien.Les gars de Microsoft ont fait généralement du bon travail avec la base de données des membres aspnet et il y a beaucoup plus de choses productives sur lesquelles se concentrer que de changer userId en int.

Answer 8

J'utiliserais un nombre à incrémentation automatique, généralement un entier.

Vous souhaitez garder la taille de la clé aussi petite que possible.Cela permet de garder votre index petit et profite également à toutes les clés étrangères.De plus, vous ne couplez pas étroitement la conception des données aux données utilisateur externes (cela est également vrai pour le GUID aspnet).

Généralement, les GUID ne constituent pas de bonnes clés primaires car ils sont volumineux et les insertions peuvent se produire potentiellement sur n'importe quelle page de données de la table plutôt qu'à la dernière page de données.La principale exception à cette règle est si vous exécutez plusieurs bases de données répliquées.Les GUID sont très utiles pour les clés dans ce scénario, mais je suppose que vous n'avez qu'une seule base de données, ce n'est donc pas un problème.

Answer 9

Si vous envisagez d'utiliser LinqToSql pour le développement, je vous recommande d'utiliser un Int comme clé primaire.J'ai rencontré de nombreux problèmes lorsque j'avais des relations construites à partir de champs non Int, même lorsque le champ nvarchar(x) avait des contraintes pour en faire un champ unique.

Je ne sais pas s'il s'agit d'un bug connu dans LinqToSql ou quoi, mais j'ai eu des problèmes avec celui-ci sur un projet en cours et j'ai dû échanger les PK et FK sur plusieurs tables.

Answer 10

Je suis d'accord avec Mike Stone.Je suggérerais également d'utiliser un GUID uniquement dans le cas où vous devez suivre une énorme quantité de données.Sinon, une simple colonne entière (Id) à incrémentation automatique suffira.

Si vous avez besoin du GUID, .NET est suffisamment beau pour que vous puissiez en obtenir un par un simple...

Dim guidProduct As Guid = Guid.NewGuid()

ou

Guid guidProduct = Guid.NewGuid();

Answer 11

Je suis également d'accord avec Mike Stone.Mon entreprise a récemment mis en place une nouvelle table d'utilisateurs pour les clients externes (par opposition aux utilisateurs internes qui s'authentifient via LDAP).Pour les utilisateurs externes, nous avons choisi de stocker le GUID comme clé primaire et de stocker le nom d'utilisateur sous forme de varchar avec des contraintes uniques sur le champ du nom d'utilisateur.

De plus, si vous envisagez de stocker le champ du mot de passe, je vous recommande fortement de stocker le mot de passe sous forme de binaire salé et haché dans la base de données.De cette façon, si quelqu’un venait à pirater votre base de données, il n’aurait pas accès aux mots de passe de vos clients.

Answer 12

J'utiliserais le guid dans mon code et comme déjà mentionné une adresse e-mail comme nom d'utilisateur.Après tout, c’est déjà unique et mémorable pour l’utilisateur.Peut-être même abandonner le guid (v.discutable).

Quelqu'un a mentionné l'utilisation d'un index clusterisé sur le GUID si celui-ci était utilisé dans votre code.J'éviterais cela, surtout si les INSERT sont élevés ;l'index sera reconstruit à chaque fois que vous INSÉREZ un enregistrement.Les index clusterisés fonctionnent bien sur les ID à incrémentation automatique, car les nouveaux enregistrements sont uniquement ajoutés.