ASP.NET MVC метод контроллера входа без использования специального поставщика членства?

Question

Мне очень любопытно, почему мне нужно создать пользовательский MembershipProvider и не должен делать что-то подобное для входа в систему потенциального пользователя.

[HttpPost]
public ActionResult Login(string username, string password)
{
    UserUnitOfWork unitOfWork = new UserUnitOfWork();
    User user = unitOfWork.UserRepository.GetByUsername(username);

    if (user != null)
    {
        SaltedHashHelper saltHelper = new SaltedHashHelper();
        if (saltHelper.VerifyHashString(username, user.Password, user.Salt))
            FormsAuthentication.SetAuthCookie(user.Username, false);
    }
    else
    {
        // User cannot be verified.
    }

    return View();
}

Если я создам пользовательский MembershipProvider, мне придется создать пользовательский MembershipUser, потому что я не использую таблицы членства asp.net. Я чувствую, что это больше головная боль, когда вы не используете таблицы членства в aspnet. Может быть, я ошибаюсь.

Кто-нибудь видит что-то не так с моим подходом выше? Мне любопытно.

Answer 1

Ваш подход хорош, если вы правильно его обрабатываете, хэшируете пароли и защищаете себя от SQL-инъекций.

Встроенные поставщики будут протестированы лучше, чем ваш пользовательский поставщик аутентификации, и могут быть более безопасными в зависимости от вашей реализации.

Answer 2

Вам не нужно создавать собственного провайдера членства, вы можете использовать то, что ASP.NET дает вам прямо из коробки. Фактически, реализация вашей собственной схемы аутентификации всегда нецелесообразна, если есть какой-либо другой выход. В худшем случае просто переопределите методы провайдера, которые вам действительно нужны, чтобы вести себя по-другому.

Взгляните на OWASP Top 10 для разработчиков .NET, часть 7. Небезопасное криптографическое хранилище , чтобы получить дополнительную информацию о том, почему это плохая идея.