Comment créer un cookie pour la connexion? Ou devrais-je m'en tenir à l'adhésion à asp.net?

Question

J'utilise asp.net MVC avec l'adhésion à asp.net, mais je commence à penser qu'il est inutile pour moi d'utiliser l'adhésion à Asp.net. Je voudrais donc savoir comment générer le même type de cookie avec les mêmes champs et celui que l'on fait pour l'appartenance asp.net.

Y a-t-il d'autres paramètres dont j'ai besoin? Comme quoi des trucs comme "User.Identity.Name" fonctionnent? Comme où cela se passe-t-il? Est-ce que ça vient du cookie ou quoi? Ou est-ce d'autre chose?

Identique à "Page.User.Identity.Name".

Est-ce que l'adhésion à asp.net définit quelque chose d'autre dont je ne suis pas au courant et qui pourrait gâcher les choses comme le Authorize Tag dans asp.net MVC? Je n'ai pas la moindre idée de la façon dont la connexion/authentification et tout ça fonctionne, puisque j'ai toujours utilisé l'adhésion à asp.net.

---

Lire ci-dessous pourquoi, si vous voulez savoir pourquoi je pense amerrissage appartenance à un asp.net

---

J'aime l'adhésion de asp.net et son bon à utiliser si vous ne semblez pas avoir à faire beaucoup de changements ou vous avez besoin de quelque chose rapidement.

Pour mes besoins, je ne pense pas que cela me convient vraiment. Je sais qu'il y a le modèle de fournisseur que vous pouvez utiliser et remplacer tout cela, mais peut-être que je ne comprends pas (je n'ai vraiment pas vraiment l'air vraiment dedans) mais je trouve ça trop contraignant. Comment je comprends que vous pouvez l'utiliser pour remplacer toutes les classes ou quelque chose comme ça. Mais si vous le surchargez, ne devrez-vous pas utiliser les mêmes paramètres et autres? Comme je suppose que vous pouvez faire de la surcharge et d'autres trucs mais qu'en est-il de ceux que vous ne pouvez plus utiliser là-bas juste en train de flotter alors vide?

Ensuite, même si vous obtenez de tout cela, j'ai toujours ce problème? J'autorise les noms d'utilisateur en double car j'ai des moyens faciles de dire quel utilisateur est qui en regardant d'autres champs. J'ai besoin de userNames en double sinon je pourrais voir des problèmes potentiels. Donc, à cause de ces noms en double, je ne peux même pas charger le site d'administration de l'adhésion à asp.net car il revient avec une erreur sur les noms en double. Ensuite, j'ai ce qui pourrait potentiellement être considéré comme 2 bases de données distinctes Je ne veux pas séparer les bases de données, car je veux garder les coûts bas. Donc maintenant j'ai 2 tables qui dérivent de la table des utilisateurs asp.net. La première table stocke les utilisateurs d'un certain type et l'autre stocke les autres utilisateurs d'un autre type, donc si je me débarrasse des tables d'adhésion asp.net, je peux les avoir comme tables de base pour ces deux tables et si jamais je décide les cracher, ce serait super facile. Donc, ces raisons et le fait que j'ai fondamentalement ma propre méthode pour tout ce dont j'ai besoin (déjà écrit) et que je n'utilise aucune méthode intégrée de l'adhésion à asp.net, je pense que je devrais juste laisser tomber et être libre de ses contraintes. Le modèle de fournisseur semble bon si vous voulez juste porter la base de données par défaut à une autre base de données telle que mysql mais autrement je ne vois juste pas un point à lui mais ceci pourrait être parce que je sais peu à son sujet.

Answer 1

Vous pouvez simplement créer votre propre schéma d'autorisation en implémentant votre attribut personnalisé et en décorant les actions du contrôleur avec, si vous en avez besoin.

Une chose à prendre en compte est la mise en cache. Si vous implémentez l'autorisation de manière simple et activez ensuite la mise en cache sur une méthode interne (compte uniquement), la sortie d'action générée en dernier sera servie à quiconque la demandera (pour la durée de mise en cache spécifiée).

Nous avons eu il y a quelques jours une discussion très similaire: Is it possible to create a Logon System with ASP.NET MVC but not use the MembershipProvider?

Answer 2

Vous pouvez facilement créer votre propre méthode d'authentification. Et je le ferais toujours pour des projets web sérieux. Le problème avec l'utilisation de systèmes comme l'adhésion est que lorsque vous trouvez qu'il manque une fonctionnalité, vous n'avez aucun moyen d'implémenter cette fonctionnalité.

La première chose à faire est de créer une page de connexion. Ici, vous implémentez la fonctionnalité de vérification du nom d'utilisateur et du mot de passe de l'utilisateur (ou du certificat, ou bien ils peuvent se connecter). Ensuite, vous stockez un cookie, représentant le nom d'utilisateur. AFAIK, abonnement asp.net stocké une version cryptée du nom d'utilisateur de l'utilisateur. C'est à mon humble avis pas très sécurisé, car un pirate aurait seulement besoin de connaître la clé de la machine du serveur afin d'usurper l'identité d'un utilisateur sur le site. J'utilise personnellement System.Security.Cryptography.RandonNumberGenerator pour générer un jeton binaire long pour l'utilisateur, que je stocke dans une table avec l'ID utilisateur. Ce jeton est ensuite remis aux utilisateurs dans un cookie.

Maintenant, vous devez implémenter l'événement Application_AuthenticateRequest. Ici, vous lisez le cookie, puis vérifiez si ce cookie correspond à un utilisateur valide. C'est ainsi, vous définissez la propriété HttpContext.Current.User à IPrincipal valide. Il existe une implémentation IPrincipal simple dans le cadre, GenericPrincipal. Cet objet contient également les rôles de l'utilisateur. Tout ce qui concerne l'authentification et l'authirozation après cela, vérifie seulement HttpContext.Current.User. Cela signifie que l'utilisateur Page.User est défini sur la valeur que vous avez définie. Si vous disposez d'un ensemble de sécurité au niveau du répertoire, certains rôles peuvent peut-être accéder à un dossier spécifique de l'application Web, etc.

Il s'agit en fait de l'ancienne méthode d'authentification par formulaires de .net 1.0. L'adhésion est juste une couche construite sur l'authentification des formulaires.

Answer 3

Tout ce que vous avez besoin est lors de la connexion réussie pour créer le cookie:

FormsAuthentication.SetAuthCookie("username", false); 

Et quand vous devez vous déconnecter simplement utiliser:

FormsAuthentication.SignOut(); 

User.Identity.Name fonctionnera, car il semble pour le cookie d'authentification et s'il est envoyé avec la requête, il va le déchiffrer et lire le nom d'utilisateur qui est stocké à l'intérieur. Vous pouvez utiliser n'importe quoi pour l'authentification et l'autorisation de l'utilisateur.