ASP.NET MVC2 и MemberShipProvider: насколько хорошо они идут вместе?

Question

У меня есть приложение ASP.NET с большим количеством пользователей и большой базой данных.Теперь я хочу иметь его в MVC 2. Я не хочу мигрировать, я делаю это более или менее с нуля.База данных, которую я хочу сохранить и не трогать слишком много.

У меня уже есть таблицы базы данных, и я также хочу сохранить LINQ to SQL-Layer.Я не использовал MembershipProvider в моей текущей реализации (в ASP.NET 1.0 это не поддерживалось).

Итак, либо я пишу свой собственный Membershipprovider для удовлетворения потребностей моей базы данных и приложения, либо я вообще не использую membershipprovider.

Я хотел бы понять последствия, если я не использую поставщика членства.Что с этим связано?Я понимаю, что в ASP.NET элементы управления логином связаны с провайдером.AccountModel, который автоматически генерируется с MVC2, может быть легко изменен для поддержки моей существующей логики.

Что происходит, когда пользователь идентифицируется AuthCookie?MVC тогда использует MembershipProvider?

Я что-то пропускаю?У меня есть те же вопросы, касающиеся RoleProvider.

Вклад приветствуется.

Answer 1

С MVC просто обойти структуру поставщика членства и роли. Иногда это проще сделать, чем внедрить пользовательских провайдеров членства / ролей, в частности, если ваша модель authn / authz не совсем соответствует форме этих провайдеров.

Во-первых, вы должны понимать, что вам не нужно писать все с нуля, вы можете использовать базовый API-интерфейс проверки подлинности с помощью форм, , который можно использовать независимо структуры поставщика членства / роли:

• FormsAuthentication.SetAuthCookie - Позвоните после того, как пользователь был авторизованный, укажите имя пользователя
• Request.IsAuthenticated - возврат истина, если SetAuthCookie был вызван
• HttpContext.Current.User.Identity.Name - возвращает имя пользователя, указанное в вызове SetAuthCookie

Итак, вот что вы делаете в MVC, чтобы обойти поставщика членства / роли:

1. Аутентификация : В вашем контроллер, аутентифицируйте пользователя используя вашу собственную логику. Если успешно, звоните FormsAuthentication.SetAuthCookie с именем пользователя.

2. Авторизация : создание кастома атрибут авторизации (производный от AuthorizeAttribute). в AuthorizeCore переопределить, внедрить ваша логика авторизации, принимая пользователя в HttpContext.Current.User.Identity.Name и роли, определенные в ролях свойство базового класса AuthorizeAttribute. Обратите внимание, что вы также можете определить свойства на свой собственный атрибут авторизации и используйте его в своей логике авторизации. Например, вы можете определить свойство, представляющее роли как перечисляемые значения специфичные для вашего приложения, вместо использования свойства Roles, которое представляет собой просто строку.

3. Прикрепите ваши контроллеры и действия с вашим настраиваемый атрибут авторизации, вместо авторизации по умолчанию приписывать.

Answer 2

Источник SQLMembershipProvider доступен здесь http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx. Возьмите это за основу.

Сначала это выглядит немного, но вам нужно только реализовать необходимые методы.*

Да, AuthCookie используется.Да, это хорошая идея использовать MembershipProvider, потому что это хорошо известно другим разработчикам.

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

Answer 3

Хотя вы, скорее всего, можете сделать это без специального поставщика членства, я не уверен, что вы сэкономите столько усилий. Пока я не прочитал этот блог Я думал, что реализовать его было сложно, но на самом деле это не так. В основном вы делаете это:

1. Создайте класс, который наследует System.Web.Security.MembershipProvider.
2. MembershipProvider является классом abstract, поэтому вам легко показать, какие методы необходимо реализовать.
3. Имена довольно понятны, так что вы, вероятно, можете более или менее скопировать существующую логику.

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