Fournisseur d'appartenances ASP.NET MVC "CreateUser"

Question

J'ai implémenté un fournisseur d'appartenances de base personnalisé pour mon application ASP.NET MVC. J'ai donc pensé que toute la validation serait effectuée dans mon code personnalisé.

Malheureusement quand je suis en train de créer un nouvel utilisateur en appelant la fonction:

Membership.CreateUser(user.UserName, user.Password, user.Email, null, null, true, Guid.NewGuid(), out status); 

qui devrait éventuellement lancer une exception avec toutes les erreurs de validation Je reçois un statut comme « InvalidUserName » ou « InvalidPassword "à la place ... Cela signifie que ma fonction CreateUser personnalisée n'est pas appelée directement, elle est utilisée après une validation de base que je souhaiterais passer.

Ma fonction CreateUser (dans mon fournisseur personnalisé):

public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion, string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status) 
{ 
    try 
    { 

     User user = new User(); 
     user.UserKey = Guid.NewGuid(); 
     user.UserName = username; 
     user.passwordSalt = string.Empty; 
     user.Password = this.TransformPassword(password, ref user.passwordSalt); 
     user.Email = email; 
     user.PasswordQuestion = passwordQuestion; 
     user.PasswordAnswer = passwordAnswer; 
     user.CreationDate = DateTime.Now; 
     user.LastActivityDate = DateTime.Now; 
     user.LastLoginDate = DateTime.MinValue; 
     user.LastPasswordChangeDate = DateTime.Now; 

     this._UsersRepository.SaveUser(user); 

     status = MembershipCreateStatus.Success; 
     return CreateMembershipFromInternalUser(user); 


    } 
    catch(RuleException ex) 
    { 
     throw ex; 
    } 
} 

Savez-vous comment faire respecter l'utilisation directe de la fonction CreateUser personnalisé!

---

Mais je ne suis pas l'aide d'un défaut de AccountController de projet ASP.NET MVC ...

Il suffit de prendre un coup d'oeil:

[AcceptVerbs(HttpVerbs.Post)] 
public ViewResult Register(User user, string password_confirm, bool acceptsTerms) 
{ 
    if (!acceptsTerms) 
     ModelState.AddModelError("acceptsTerms", "Musisz zaakceptować regulamin"); 

    if (ModelState.IsValid) 
    { 
     try 
     { 
      MembershipCreateStatus status = new MembershipCreateStatus(); 
      Membership.CreateUser(user.UserName, user.Password, user.Email, null, null, true, Guid.NewGuid(), out status); 
     } 
     catch (RuleException ex){ 
      ex.CopyToModelState(ModelState,"user"); 
     } 
    } 

    return View(); 
} 

Le point est que je reçois un statut au lieu de RuleException ex lorsque user.UserName ou user.Password est vide. Mon RuleException ex personnalisé me donnerait aussi ces informations. Où une valeur de statut est assignée maintenant!? Bacouse cela ne se fait pas dans ma mise en œuvre de CreateUser ...

Answer 1

Réécriture complète

Le système ASP.NET Membership fait toujours une première validation des entrées lorsque des API telles que CreateUser sont appelés.

Je ne connais aucun moyen de contourner cela à part de ne pas aller directement aux API d'adhésion ASP.NET.

Answer 2

J'utilise ce (MVC3) et j'ai aucun problème:

[HttpPost] 
public ActionResult Register(RegisterModel model) 
{ 
    if (ModelState.IsValid) 
    { 
     MembershipCreateStatus status; 
     Membership.Provider.CreateUser(model.UserName, model.Password, model.Email, "", "", true, Guid.NewGuid(), out status); 

     if (status == MembershipCreateStatus.Success) 
     { 
      FormsService.SignIn(model.UserName, false); 
      return RedirectToAction("Index", "Home"); 
     } 
     else 
     { 
      ModelState.AddModelError("", AccountValidation.ErrorCodeToString(status)); 
     } 
    } 

    // If we got this far, something failed, redisplay form 
    ViewBag.PasswordLength = MembershipService.MinPasswordLength; 
    return View(model); 
} 

Answer 3

Utilisation ILSpy pour afficher la méthode statique Membership.CreateUser, vous trouverez effectue une validation sur

• Nom d'utilisateur (mot de passe (espace blanc + non nul, non vide)
• Mot de passe (espace blanc de découpage + non nul, non vide, contrôles de longueur)
• E-mail (espace blanc de garniture)
• Question de mot de passe (trim + espaces non vide)
• Password Réponse (suppression des espaces + non vide)

Il appelle ensuite le fournisseur personnalisé.

La clé ici est de ne pas appeler la méthode statique CreateUser

Membership.CreateUser(...) 

plutôt appeler le fournisseur personnalisé directement en utilisant:

Membership.Provider.CreateUser(...) 

testé et vérifié de travail, à partir de 4 .NET

Alors que mon site recommande d'avoir un mot de passe, nous soutenons openid. Donc, forcer un utilisateur à avoir un mot de passe semblait aller à l'encontre de ce pour quoi openid est bon.