Проверка подлинности ASP.NET MVC с использованием пользовательской базы данных вместо ASPNETDB?

Я отвечу на ваши обновленные вопросы:

Мне нужно написать свой собственный MemberhipProvider?

Если вы (а) хотите продолжить использование проверки подлинности с помощью форм и (b) иметь структуру таблицы авторизации, которая не соответствует тем же соглашениям, что и ASPNETDB, то да. Если вам не нужен FormsAuth (см. Ниже), вы можете полностью отказаться от MembershipProvider, но я бы не рекомендовал его. Или, если вы используете те же самые таблицы безопасности, что и ASPNETDB, но просто хотите указать его на другую базу данных, вы можете продолжить использовать поставщик по умолчанию и просто изменить его конфигурацию.

Какие изменения мне нужно внести в файл web.config?

Если вы используете свой собственный MembershipProvider, вам необходимо зарегистрировать его в разделе <providers> элемента <membership> и изменить свойство defaultProvider. Если вы используете стандартный AspNetSqlProvider, вам, вероятно, просто нужно будет изменить строку подключения.

Будет ли атрибут [Authorize] работать, если я напишу собственное решение?

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

Можно ли использовать автоматически созданный AccountController с некоторыми незначительными изменениями или мне в основном нужно переписать контроллер учетной записи с нуля?

Вы должны переписать AccountController в любом случае - не оставляйте демонстрационный код в производственном приложении. Но если вам нужно - да, AccountController будет работать в тех же условиях, что и выше.

просто строить то же самое, поэтому ответ на 1 должен быть НЕТ:) Я использую стандартную аутентификацию форм asp.net, где я использую метод FormsAuthentication.RedirectFromLoginPage(имя пользователя, createCookieBool) для входа пользователя в систему. Я дал пользователю уникальный guid (вы можете использовать любой другой идентификатор пользователя), и я сохраняю его в параметре UserName вместе с именем пользователя (для отображения на главной странице: Html.Encode(Page.User.Identity.Name.Split( "|".ToCharArray()) [1]))

В каждом контроллере/методе, в котором я должен знать, какой пользователь зарегистрирован (через User.Identity.Name, разделите строку и получите userguid). Также я украшаю эти процедуры атрибутом [Authorize].

Мы делаем именно это в одном из наших приложений и находим его довольно простым. У нас есть служба проверки подлинности (называемая контроллером), которая обрабатывает механику хэширования введенного пароля, чтобы убедиться, что это совпадение, а затем просто возвращает bool для метода, который мы называем "IsValidLogon".

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

Мы принципиально игнорировали ASPNETDB. Если мы получим правильный ответ от нашей проверки пользователя/пароля, мы просто вызываем стандартную форму FormsAuthentication.RedirectFromLoginPage(имя пользователя, createCookieBool);

Надеюсь, что это поможет.

• Нет. И я бы подозревал, что большинство людей не доверяют этому кропотливому механизму

• Не так много, тем более, что у вас уже есть таблица.

• Взгляните на это, например: http://forums.asp.net/t/1250726.aspx