Проверка на данните в ASP.NET Identity

В тази статия ще продължим да проектираме нашия прост проект за управление на потребители и ще разгледаме възможностите за валидиране (валидиране) на въведените данни при създаването на нови потребители.

Проверка на паролата

Едно от най-често срещаните изисквания, особено при разработването на корпоративни приложения, е да се контролира сложността на паролите, които потребителите използват, за да влязат в акаунта си. ASP.NET Identity включва Клас PasswordValidator, с които можете да конфигурирате системата за сложността на проверката на паролата, като използвате свойствата, изброени в таблицата по-долу:

Задава минимално разрешената дължина на паролата

Ако е зададено на true, паролата трябва да съдържа поне един знак, който не е нито буква, нито номер

Ако е зададено на true, паролата трябва да съдържа цифри

Ако е зададено на true, паролата трябва да съдържа малки букви

Ако е зададено на true, паролата трябва да съдържа главни букви

Политиката за пароли се задава чрез създаване на екземпляр на класа PasswordValidator, задаване на стойностите на неговите свойства и използване на този обект като стойност за свойството PasswordValidator на класа UserManager в метода Create:

true паролата

Внедряване на валидиране на персонализирана парола

Вградените възможности за проверка на пароли са достатъчни за повечето приложения. Може обаче да се наложи да създадете сложни проверки на парола, които надхвърлят стандартните свойства на класа PasswordValidator. Можете да разширите основните възможности за проверка на паролата, като създадете клас, който наследява от PasswordValidator и замества неговия метод ValidateAsync (). Добавете файла с класа на CustomPasswordValidator.cs към папката Инфраструктура със следното съдържание:

В този пример сме заменили метода ValidateAsync () и първо сме извикали основната реализация на този метод, за да стартираме вградената проверка. След това добавихме проверка на персонализирана парола, за да видим дали тя съдържа поредицата от числа „12345“. Свойството Errors на обекта IdentityResult е само за четене, така че за да върнем списък с грешки, създадохме нов обект IdentityResult и комбинирахме грешките от основната проверка на паролата с грешките от персонализираната проверка. Използвал съм LINQ, за да свържа тези грешки.

Следващият пример демонстрира използването на новия клас на валидатор:

За да тествате проверка на персонализирана парола, опитайте да създадете нов потребителски акаунт с паролата „secret12345“. Тази парола нарушава две правила за валидиране - едно за вградено валидиране и едно за валидиране по поръчка. И двете грешки ще се покажат при опит за създаване на нов потребител:

идентичност

Проверка на потребителските данни

По-общи проверки могат да бъдат направени чрез създаване на инстанция на класа UserValidator и използвайки неговите свойства от таблицата по-долу:

Ако е зададено на true, потребителските имена могат да съдържат само букви и цифри

Проверката на потребителските данни се извършва по същия начин като проверката на пароли - на свойството UserValidator от класа UserManager се присвоява обект UserValidator с предварително инициализирани свойства:

Класът UserValidator приема общ тип, който сочи към класа на описанието на потребителя (в нашия случай това е AppUser). Екземпляр от типа UserManager се предава на конструктора на класа UserValidator, за да обвърже проверката на потребителските данни с класа на потребителския модел.

Освен за проверка на паролата, можете да разширите проверката на потребителските данни, като създадете клас, наследен от UserValidator. Като пример добавете файла CustomUserValidator.cs към папката „Инфраструктура“ на проекта със следното съдържание:

зададено true

Промени в текста на грешки при проверка

По-рано казах, че ще ви покажа как да променяте текстовете на стандартни грешки при валидиране. Очевидно грешките на английски език са неприемливи за приложение на руски език. И така, трябва да приложим интерфейса за валидатор IIdentityValidator, където T е типът на проверяваното поле. Например класът PasswordValidator, обсъден по-горе, реализира интерфейса IIdentityValidator, а класът UserValidator реализира IIdentityValidator. Например, нека променим дефиницията на класа CustomUserValidator:

В този пример проверяваме ръчно попълването на полето и списъка с валидни знаци в потребителското име. Също така трябва да промените повикването към помощния клас за проверка в метода Create () на класа AppUserManager: