Контроль входа и пользовательское членство провайдера - PullRequest
Новая
       9

Контроль входа и пользовательское членство провайдера

6 голосов
/ 11 октября 2010

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

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

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

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

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

Ответы [ 3 ]

4 голосов
/ 12 октября 2010

Вы правы.Чтобы реализовать логику, о которой вы говорите, вам нужно реализовать событие 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.Удачного кодирования ...

2 голосов
/ 11 октября 2010

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

Провайдер членства. Метод ChangePassword, тип возвращаемого значения

1 голос
/ 12 октября 2010

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

...