2010-12-09 17 views
0

J'ai une application ASP.NET MVC qui utilise le fournisseur d'appartenance ASP.NET par défaut.Blocage de l'accès à l'application pour un utilisateur

Mon client a demandé d'implémenter une fonctionnalité qui empêche les utilisateurs de se connecter (par exemple, pour les utilisateurs qui démissionnent et quittent l'entreprise).

Je ne peux pas utiliser l'indicateur IsApproved de la table Membership car ce champ est utilisé pour confirmer l'inscription de l'utilisateur.

Y at-il une fonctionnalité intégrée pour cela? Quelles sont vos expériences dans des scénarios comme celui-ci?

+0

Utilisez-vous des verrouillages de compte? –

+0

@adrift: Non. Puis-je les utiliser pour mes besoins? – Lorenzo

+0

oui, si IsLockedOut est vrai, un utilisateur ne pourra pas se connecter jusqu'à ce que le verrouillage soit effacé. –

Répondre

1

Puisque vous n'utilisez pas les verrouillages de compte, vous pouvez utiliser le drapeau IsLockedOut pour cela. Si IsLockedOut est true, un utilisateur ne pourra pas se connecter jusqu'à ce qu'il soit effacé.

Pour plus d'informations sur la manière dont cette propriété est généralement utilisée, voir MembershipUser.IsLockedOut.

Si vous voulez éviter d'utiliser IsLockedOut pour cela, et en supposant que vous utilisez le SqlMembershipProvider, une autre option serait de modifier directement la procédure que le fournisseur appelle pendant le processus de connexion: aspnet_Membership_GetPasswordWithFormat.

Si vous vérifiez le code de cette procédure, vous verrez que si l'utilisateur n'existe pas ou est verrouillé, il renvoie un résultat non nul:

IF (@UserId IS NULL) 
    RETURN 1 

IF (@IsLockedOut = 1) 
    RETURN 99 

Vous pouvez maintenir la liste des utilisateurs bloqués dans une table séparée et vérifier ici. L'inconvénient est que si cette procédure est jamais recréée ou que le site est remplacé par une nouvelle base de données d'appartenance, ces modifications pourraient être perdues.

Entre ces deux options, je choisirais d'utiliser IsLockedOut, mais j'ai pensé ajouter une autre option au cas où il y aurait une forte préférence à l'utiliser de cette façon.

HTH

+0

Vous avez définitivement raison. La meilleure option que je pense est de coder une méthode 'LockUser' dans ma couche de service qui essaierait de provoquer l'un des scénarios décrits dans la section des remarques [ici] (http://msdn.microsoft.com/fr-fr/ library/system.web.security.membershipuser.islockedout.aspx). Merci pour ton aide! – Lorenzo