Контроль доступа и поставщик пользовательского членства

Question

Я работаю над внедрением пользовательского поставщика членства, который работает против существующей схемы в моей базе данных и имеет несколько мыслей/вопросов.

Элемент управления доступом автоматически вызывается методом ValidateUser поставщика членства, поэтому независимо от того, как я реализую провайдера, единственное, что беспокоит управление login, - это значение bool, возвращаемое этим методом. То, что меня смущает, может быть множество причин, по которым попытка входа в систему не удалась; пользователь заблокирован, слишком много попыток за определенный промежуток времени и т. д. Я не вижу способа передать это элементу управления, чтобы он мог отображать правильное сообщение. Другие свойства поставщика членства, такие как PasswordStrengthRegularExpression, абсолютно не влияют на контроль входа в систему (из коробки), я бы надеялся, что он автоматически каким-то образом преобразует в валидаторы регулярных выражений, но это, похоже, не является дело. Похоже, мне нужно инициализировать свойства управления входом с этими настройками из конфигурации поставщика, если я хочу, чтобы они сами взяли сам элемент управления.

Если единственное, что элемент управления входами извне (без ручного управления событиями и выполнения инициализации, как описано выше), вызывает метод ValidateUser у поставщика членства, я не вижу возможности вернуться к входу в систему контролировать, почему валидация не удалась или даже делала такие вещи, как регулирование запросов проверки на основе определенного временного окна. В конечном счете, мой вопрос заключается в том, почему я бы даже использовал поставщика членства, а затем в сочетании с контролем входа? Похоже, он был разработан только для ответа типа «Да/Нет», который очень ограничительный. Если я хочу построить логику с разными сообщениями обратно пользователю, мне нужно обработать события управления входами и вызвать мои собственные классы проверки подлинности, которые будут обрабатывать все мои бизнес-требования, а также возвращать настраиваемое сообщение об ошибке обратно в элемент управления Login показ пользователю, чтобы они знали, почему их попытка недействительна.

Если я ошибаюсь в своих предположениях, кажется, что интерфейс между элементом управления Login как API-интерфейсом членства является слишком ограничительным, чтобы быть полезным. Возможно, API работает лучше для других аут-контролов, таких как ChangePassword, но для фактического управления входом я не вижу смысла.

Я ценю ваши мысли.

Answer 1

Вы правы. Чтобы реализовать логику, о которой вы говорите, вам необходимо реализовать событие Authenticate. Таким образом, вы можете написать собственное сообщение об ошибке после своей собственной проверки.

С другой стороны, я не думаю, что сила пароля должна быть проверена при аутентификации, а скорее на создании пользователя.

вы могли бы написать что-то вроде этого:

protected void Login_Authenticate(object sender, AuthenticateEventArgs e) 
{ 
    try 
    { 
     e.Authenticated = myMembershipProvider.ValidateUser(LoginControl1.UserName,LoginControl.Password); 

    } 
    catch(Exception ex) 
    { 
     LoginControl1.FailrureText = ex.Message; 
    } 
} 

И бросить свое собственное исключение в методе ValidateUser. Счастливое кодирование ...

Answer 2

У меня была такая же проблема при использовании метода, связанного с подключением (сменить пароль) с помощью поставщика членства, где я хотел получить больше информации, а затем просто да/нет. Надеюсь, вы можете реализовать решение, подобное обходному пути, с которым я столкнулся. Смотрите это:

Membership provider ChangePassword method return type problem

Answer 3

Okey, если вы не можете изменить элемент управления входами, вам в конечном итоге понадобится другой интерфейс для входа в систему!