Контроль входа в систему и настраиваемый поставщик членства

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

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

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

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

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