asp.net MVC Password validation

Prøvede lige at oprette et nyt MVC4 projekt, for at se hvad Microsoft gør. Det må jo anses for at være bedst practice.

Hurtigt forklaret, så har de to modeller. En til registrering og en til login:

 public class LoginModel
     {
         [Required]
         [Display(Name = "User name")]
         public string UserName { get; set; }
 
         [Required]
         [DataType(DataType.Password)]
         [Display(Name = "Password")]
         public string Password { get; set; }
 
         [Display(Name = "Remember me?")]
         public bool RememberMe { get; set; }
     }
 
     public class RegisterModel
     {
         [Required]
         [Display(Name = "User name")]
         public string UserName { get; set; }
 
         [Required]
         [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
         [DataType(DataType.Password)]
         [Display(Name = "Password")]
         public string Password { get; set; }
 
         [DataType(DataType.Password)]
         [Display(Name = "Confirm password")]
         [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
         public string ConfirmPassword { get; set; }
     }

Giver dig ret i, at det kan virke ulogisk, men det er jo egentlig meget logisk, da det er tvivlsom at det er de samme felter der skal bruges når man registrerer sig og når man logger ind.

Du kan dog også vælge at disable validering for den enkelte action:

 [HttpPost]
 [AllowAnonymous]
 [ValidateInput(false)]
 public ActionResult Login(LoginModel model, string returnUrl)
 {
 }

Det disabler så vidt jeg ved ikke clientside validering. Det kan du gøre i dit View med:

 @model MyMvcApplication.Models.LoginModel
 @{
     ViewBag.Title = "Login";
     HtmlHelper.ClientValidationEnabled = false;
 }

Håber det hjalp dig lidt

@Nicky
Tak! Se sådan nogle svar kan vi kun få flere af!

Men ja synes det er lidt spildt arbejde at have hver sin model, men måske jeg laver noget nedarvning i stedet bare for at lave det pænt og på en måde jeg rent faktisk synes kan være i orden uden at have to identiske (læs: meget meget ens) modeller.

Det med jeg kan disable min validering.
Mener du jeg ville kunne bruge samme model og så disable validering når den bruges i det ene scenarie?

Velbekomme - der var endelig noget jeg vidste bare lidt om

Tja, ved ikke om jeg vil kalde det for spild. Oftest så har man jo en UserModel der indeholder mere end blot brugernavn og adgangskode. Typisk vil man have også have personens navn, kontrol af kode og evt. e-mail. I det scenarie, hvor man typisk vil have regler for validering synes jeg ikke det er spild. Tvært imod giver det god mening, da man opbygger sine views udfra modeller.

Det er også nemmere at vedligeholde ved at holde det adskilt. Ellers kræver det en indafgående viden omkring at man vælger at basere et view på en model der ikke bruges fuldt ud, og at man ignorer de opstillede regler.

Men ja, du burde kunne omgå det ved at disable validering i dit scenarie.

Arv i MVC4, er lidt tricky.

Du skal override default modelbinder, til at tage højde for at der er flere elementer der kan tage have samme basetype. Det kan du bl.a. gøre ved at have et hiddenfield, der fortæller hvad type det er (evt typeof(Model).FullName). Og så modelbinderen læse den værdi og initialisere et objekt af den type.

Personligt ville jeg løse det hele ved at have de to forskellige modeller. En UserModel og en LoginModel.

Jeg synes det er en dårlig måde fordi du ønsker samme funktionalitet på to klasser, og nogle afvigelser. Hvis du laver samme funktionalitet og implementering to steder er det redundant kode, med chance for du glemmer at opdatere når du vil rette noget til.

Jeg har tænkt på at lave følgende:

 public abstract class UserModel
     {
         public int ID { get; set; }
 
         [Required]
         [Display(Name = "E-mail")]
         public string Email { get; set; }
         
         [Required]
         [Display(Name = "Adgangskode")]
         [DataType(DataType.Password)]
         [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
         public string Password { get; set; }
     }
 
     public class RegisterModel : UserModel
     {
         [Required]
         [DataType(DataType.Password)]
         [Display(Name = "Bekræft adgangskode")]
         [Compare("Password", ErrorMessage = "Adgangskoderne skal være ens.")]
         public string PasswordValidation { get; set; }
     }
 
     public class LoginModel : UserModel
     {
         public bool RememberMe { get; set; }
     }

Så kan jeg bruge RegisterModel og LoginModel.
Jeg er ikke helt sikker på jeg forstår problematikken i at have to klasser der begge arver fra en base-class? Den bør jo stadig se det som den endelige klasse.

Jeg synes det er en dårlig måde fordi du ønsker samme funktionalitet på to klasser, og nogle afvigelser. Hvis du laver samme funktionalitet og implementering to steder er det redundant kode, med chance for du glemmer at opdatere når du vil rette noget til.

Det kan der være noget om, men det er ikke så tit at man ændrer i at man skal angive brugernavn og adgangskode for at logge på

Hvad hvis man gerne vil giver brugerne mulighed for at huske sit login?

Eller ikke vil have validering på login siden? F.eks. har jeg ikke noget i mod, at der bliver kontrolleret clientside at både brugernavn og adgangskode er udfyldt, men jeg vil aldrig fortælle at der skal være mindst 6 tegn i password ved login.

Så kan jeg bruge RegisterModel og LoginModel.
Jeg er ikke helt sikker på jeg forstår problematikken i at have to klasser der begge arver fra en base-class? Den bør jo stadig se det som den endelige klasse.

I forbindelse med min hovedopgave havde jeg 3-4 forskellige klasser der alle arvede fra en baseclass. Min controller vidste at, den skulle tage i mod nogle elementer der alle samme var nedarvet fra den klasse, men den kunne ikke selv finde ud af at fortolke, hvilken type de enkelte elementer bestod af. Også selvom der (tildels) var en væsentlig forskel på hvilke properties hver klasse bestod af. Derfor var det nødvendigt at override default modelbinder, og tilføje det hidden field med navnet på typen