Quels sont les avantages et les inconvénients asp.net membre?

je construis un nouveau site web et un ami me suggère d'utiliser le asp.net adhésion pour le processus d'authentification (login, inscription, récupération de mot de passe, etc..).

j'ai vu que tout est stocké dans un fichier XML.

je voudrais savoir quels sont les avantages et les inconvénients de l'adhésion au lieu de construire quelque chose à partir de zéro.

15
demandé sur Andrea Turri 2010-11-23 14:32:23

6 réponses

la solution de connexion MS se compose de plusieurs parties.

Authentification "Qui peut accéder à votre site"

L'Authentification De Formulaires - cela crée essentiellement un cookie sécurisé qui dit "je suis authentifié!"à chaque requête. Sans cela, les utilisateurs devraient se connecter à chaque page.

  • Avantages: Cela fonctionne bien
  • Inconvénients: Aucun - utiliser

Membres - Voici comment vous Enregistrez vos utilisateurs et leurs mots de passe, et valider les justificatifs d'identité des utilisateurs. Il y a plusieurs façons de procéder:

  1. Using the Sqlmembershippprovider - Microsoft vous donne une base de données pour stocker les utilisateurs/mots de passe en toute sécurité, et vous donne un moyen d'authentifier les références.
    • Pros:
      • Moins/pas de code personnalisé à maintenir. Works "out of the box"
      • fonctionne avec les contrôles D'adhésion et API
    • Cons:
      • vous devez utiliser un serveur Sql et utiliser leur schéma de base de données. (pas un problème de l'OMI)
      • aucun contrôle sur la façon dont les mots de passe sont générés au départ. Ils sont longs et laids!--10-->
      • courbe D'apprentissage plus abrupte à mesure que vous vous familiarisez avec la technologie

  2. Création d'un custom MembershipProvider - vous pouvez hériter de Membershippprovider pour personnaliser où et la façon dont vous stockez vos données.

    • Pros:
      • vous obtenez le cryptage / déchiffrement des mots de passe gratuitement
      • contrôle de l'endroit où vous stockez vos utilisateurs et de ce que les données ressemblent
      • vous pouvez toujours utiliser les contrôles D'adhésion et L'API
    • Cons:
      • doit implémenter votre propre solution de stockage
      • vous devez écrire, déboguer, et maintenir beaucoup de code personnalisé
      • Si vous ajoutez des fonctionnalités supplémentaires, vous devez lancer le fournisseur à utiliser

  3. Créer votre propre schéma d'Authentification

    • Pour: le contrôle Complet
    • Cons:
      • vous créez tout, mais devez déboguer / maintenir tout.
      • vous devez contrôler vous-même la sécurité des justificatifs d'identité.
      • ne peut pas utiliser les contrôles D'adhésion (ce n'est pas une grande perte car les contrôles sont assez simple à répliquer)
      • vous ne Pouvez pas utiliser l'Adhésion de l'API

autorisation - " que peuvent faire les utilisateurs?"

Rôles - Rôles de contrôler ce que les utilisateurs peuvent le faire via le mécanisme d'autorisation fourni par le web.config et travaille également avec les mesures de sécurité sur le plan du site.

  1. Utilisation de la SqlRoleProvider - Microsoft vous donne une base de données à stocker les rôles

    • Pros:
      • Fonctionne avec le web.config
      • Vous pouvez assigner plus d'un rôle à un utilisateur
    • Cons:
      • Rôles sont juste une chaîne de caractères, pas de "hiérarchie des" autorisations de soutien. Cela peut rendre difficile la création de règles autour desquelles les utilisateurs peuvent éditer d'autres utilisateurs.

  2. Création d'un custom RoleProvider - vous pouvez hériter de RoleProvider pour personnaliser où et comment vous stockez vos données.

    • Avantages: Fonctionne avec le web.config
    • Cons:
      • doit implémenter votre propre solution de stockage
      • Encore juste un string et sont aussi limitées que la solution précédente
      • si vous ne l'implémentez pas correctement, il pourrait faire beaucoup d'appels de bases de données.

  3. Créer votre propre schéma d'Authentification

    • Pros: Contrôle complet - faites juste des vérifications personnalisées sur votre page et erreur / redirection si nécessaire
    • Cons:
      • Ne fonctionne pas avec le mécanisme d'autorisation fournie par le web.config / sitemap. En pratique, cela signifie que l'ajout d'une page à un dossier (tel que /Admin) ne garantit plus la sécurité de cette page.

il est important de noter que les membres et les fournisseurs de rôle peuvent être choisis ou personnalisé indépendamment les uns des autres. Je recommande personnellement L'utilisation du SqlMembershipProvider si vous le pouvez et l'évaluation de vos options pour le fournisseur de rôle.

29
répondu Greg 2010-11-29 15:32:21

je n'aime pas l'utilisation du Fournisseur d'appartenances.

c'est jusqu'à quand le scénario est "standard", mais dans les cas où vous avez besoin de plus de règles personnalisées, je pense que cela ne fonctionne pas bien. Apparaissent "solutions de contournement".

et pas besoin de stocker dans un XML, existe une autre solution (base de données, par exemple).

3
répondu 19WAS85 2010-11-23 11:42:13

contre:

  • votre datastore préféré pourrait ne pas être entièrement supporté hors de la boîte

  • Il peut ne pas correspondre à vos exigences actuelles ou futures

  • Vous ne pourriez pas comprendre pleinement les subtilités de la façon dont il fonctionne (en plus de quelque chose que vous avez construit vous-même)

Avantages:

  • Vous pouvez gagner du temps par rapport à rouler votre propre.

Personnellement... si c'est un projet sérieux, je voudrais rouler (mais bien sûr garder l'authentification de formulaires). D'après mon expérience, un grand nombre de ces caractéristiques "hors de la boîte" des SP sont plutôt à moitié assed.

3
répondu UpTheCreek 2010-11-23 11:44:18

the nice thing about ASP.Net L'adhésion est que vous pouvez utiliser autant ou aussi peu que vous voulez - vous pouvez stocker des données d'utilisateur dans diverses formes( comme d'autres l'ont mentionné), ou vous pouvez juste utiliser ASP.Net adhésion pour gérer l'autorisation de session et la protection de page.

par exemple, vous pouvez aller le hog entier et utiliser le contrôle de login, le SQLMembershipProvider back end et juste laisser ASP.Net L'adhésion fait tout de bout en bout.

Ou vous pouvez stocker vos propres nom d'utilisateur et mots de passe, dans votre propre table de base de données, authentifiez les détails fournis vous-même et puis il suffit d'utiliser "FormsAuthentication.RedirectFromLoginPage () " to tell ASP.Net l'adhésion que l'utilisateur est authentifié, et ont ASP.Net L'adhésion contrôle alors l'accès aux pages.

ASP.Net L'adhésion est essayée et testée, elle est utilisée par des milliers de sites à L'intérieur et à l'extérieur de Microsoft, donc vous savez que le code fonctionne et fonctionne bien. S'il y a un problème, alors il y a de nombreuses implémentations de là que va le trouver. Votre propre approche n'a qu'un seul utilisateur...

3
répondu Moo 2010-11-23 11:54:44

en fait, tout n'est pas nécessairement stocké dans un fichier XML. Vous pouvez stocker les données de Membership de plusieurs façons, y compris une base de données.

vous pouvez également utiliser le ASP.NET les rôles / la bibliothèque de membres comme point de départ pour rouler votre propre. Il y a quelques tutoriels pour faire ceci autour des interwebs.

le Pro avec l'utilisation des fonctions intégrées est que le ASP.NET gui d'adhésion-contrôles plus ou moins"juste le travail".. ;)

1
répondu Christian Wattengård 2010-11-23 11:38:04

à mon avis, les fournisseurs d'abonnement .NET sont une excellente façon de faire quoi qu'il en soit. J'ai écrit quelques grandes applications les utilisant. Si votre architecture est bonne, il est assez simple d'ajouter des fonctionnalités et de modifier les données dans les prochaines versions.

voici un peu de contexte pour encadrer mes réponses. L'adhésion/rôle/profil de solutions .NET se composent de deux parties: le cadre et les fournisseurs. Le cadre comprend les méthodes et les informations de votre programme interagir avec. Les fournisseurs déterminent comment les données seront stockées.

je trouve que le cadre est excellent. Il n'y a pas grand chose que vous ne pouvez pas faire indépendamment de la façon dont vous voulez interagir avec elle. Les implémentations par défaut vous donnent beaucoup gratuitement. Tout manque de fonctionnalité est encore atténué si vous utilisez de bonnes pratiques de codage. Voir le démarreur ASP.NET application MVC pour un excellent exemple de l'emballage la composition du cadre.

les données ne semblent jamais pour travailler comme tu veux, mais c'est rien que tu ne puisses pas contourner. Tout d'abord, comme les gens l'ont dit, il y a un tas de fournisseurs expédiés avec .NET. Et c'est également là que la mise en œuvre de votre propre fournisseur entre en jeu. Nous commençons habituellement par sous-classer SqlMembershipProvider. Si quelque chose ne fonctionne pas comme on veut, on l'annule. Et changer les tableaux de données plus tard si nécessaire n'est pas très difficile.

utiliser ce qui existe déjà semble toujours nous laisser obtenir aller vite et de s'adapter selon les besoins. En vérité, les changements à ce code ne se produisent pas souvent. L'utilisation de la solution Microsoft au début pourrait ne pas aboutir avec le plus beau morceau de travail, mais il obtient le travail fait rapidement et vous permet de passer à la résolution des problèmes importants.

1
répondu Chuck 2010-11-23 12:04:50