ASP.NET MVC 2 - Fournisseur d'appartenances - ValidateUser() - retourne le login message d'erreur
Comment puis-je retourner un message de chaîne à partir de la méthode ValidateUser à mon fournisseur d'appartenances personnalisé? J'ai besoin de cela parce que je veux effectuer plusieurs contrôles (utilisateur est approuvé, l'utilisateur est bloqué, etc.) et donner à l'utilisateur une bonne description, si le processus d'ouverture de session échoue.
Une option serait de lancer une exception, mais quelqu'un a dit que ce n'est pas un moyen approprié pour le traitement de telles situations.
Pour l'instant, je peux seulement dire "échec de la Connexion" ou "Connexion réussie" en raison de l'bool type de retour.
Est-il possible de créer ma propre méthode ValidateUser ou ne l'ASP.NET l'Adhésion mécanisme utilise celui par défaut dans les opérations internes?
Merci pour l'astuce de Lazare.
C'est un manque à gagner de la MembershipProvider. ValidateUser() renvoie un booléen, vous laissant avec de MAUVAISES options. 1) actualiser la base de données pour plus d'informations (frais généraux), 2) ajouter des méthodes et jeter votre fournisseur (rupture de l'indépendance), ou 3) un groupe témoin de fonctionnement. MS devrait mettre à jour le fournisseur. Ce serait formidable si ValidateUser retourné, au minimum, et enum AuthenticationStatuts comme CreateUser() renvoie un MembershipCreateStatus enum. Bien, je voudrais voir quelque chose d'un peu plus que même les MembershipCreateStatus enum est limité (forums.asp.net/t/1521981.aspx).
OriginalL'auteur Cosmo | 2010-03-03
Vous devez vous connecter pour publier un commentaire.
Ceux sont deux opérations différentes.
Pour voir si un utilisateur est approuvé, lock-out, etc., rechercher l'utilisateur (avec
GetUser()
) et regardez leIsApproved
,IsLockedOut
, etc. propriétés de l'utilisateur retourné.ValidateUser()
est uniquement pour la connexion, mais vous pouvez faire les deux.Je pense que je serais sous-type
MembershipUser
plutôt que de le remplacer, mais avant de le faire, la note (1) il existe déjà de biens destinés à être spécifiques à l'application les données de msdn.microsoft.com/en-us/library/... et (2) spécifiques à l'application les infos de l'utilisateur est souvent mieux adapté pour l'Identité que sur une adhésion de l'utilisateur. L'adhésion des utilisateurs vraiment juste dire que vous pouvez obtenir dans. L'identité dit qui vous êtes.Oh, et c'est sans doute évident, mais vous avez seulement besoin de regarder pour l'utilisateur si la connexion échoue. Si elle réussit, elle doit être approuvée, et ne peut pas être verrouillé.
"Si elle réussit, elle doit être approuvée, et ne peut pas être verrouillé" - à la suite de cela, suis-je en droit que le cookie d'authentification doivent être définis uniquement après vérification de ValidateUser et les autres propriétés (verrouillé, approuvé...)? Je veux dire: (nom d'utilisateur, Mot de passe) -> ValidateUser() -> GetUser().IsApproved -> GetUser().IsLockedOut -> SetAuthCookie(). Est-ce l'ordre correct?
réitérer ce que craig a - Si un utilisateur est verrouillé ou non approuvée, la validation sera de retour faux. Seulement si vous avez mis en œuvre un fournisseur personnalisé ou hérité d'un fournisseur et souhaitez réagir à différentes raisons, dire de faire passer un message à la page, auriez-vous besoin pour vérifier la IsXXX propriétés.
OriginalL'auteur Craig Stuntz
Vous peut mettre en œuvre tout les méthodes que vous souhaitez sur votre fournisseur personnalisé, et dans votre cas, il pourrait du bon sens et de jeter l'Adhésion à votre type avant de l'utiliser.
Mais rupture de l'interface pour obtenir un peu simple de bande info peut revenir à vous mordre dans le futur. Il y a d'autres façons de le faire et de préserver l'api fournisseur et de garder votre avenir options ouvertes.
Dans le passé, j'ai utilisé un cookie pour pass out-of-band info comme celle d'un fournisseur au consommateur.
La HttpContext.Le courant est le même pour le fournisseur que pour la page de sorte qu'un cookie défini dans le fournisseur peut être lu à la consommation.
Assurez-vous juste que vous supprimer le cookie après l'appel de votre fournisseur. La création d'un témoin transitoire permet de minimiser les erreurs, mais il suffit de retirer de la collecte, de toute façon.
Ici est un exemple.
CookieChannelMembershipProvider
Web.config
Par défaut.aspx
OriginalL'auteur Sky Sanders
Vous devez créer votre propre mécanisme; cela n'arrive pas par défaut et ne peut pas être fait avec l'appartenance intégré de fournisseur. Vous pouvez rassembler que fournisseur et ajouter cette méthode et faire vous-même... c'est une option. Mais alors, cela ne fonctionne pas en ligne avec le contrôle de connexion si vous l'utilisez.
OriginalL'auteur Brian Mains