Должен ли я использовать встроенный поставщик членства для приложения ASP .NET MVC?

Question

До сих пор я использовал собственный провайдер членства для аутентификации во всех моих приложениях веб-форм. Я собираюсь начать разработку моего первого сайта с использованием MVC. Мне интересно, должен ли я использовать встроенный поставщик членства, который поставляется с ASP .NET MVC, или мне следует создать свой собственный. Мой сайт должен интегрироваться с openid, facebook, google и т. Д. Для аутентификации и openauth для доступа к API. Мне интересно, насколько легко было бы использовать встроенный для моих нужд.

Answer 1

Лично я ненавижу , используя ASP.NET Membership provider, который доступен в базовой структуре ... , когда он сохраняется в базе данных SQL SERVER . Все таблицы и представления являются излишним для одного сайта. Для хостинговой компании? ... может быть ... но для всех корпоративных сайтов, которые я сделал ... это было излишним излишеством и хлопотами. Что касается фактического интерфейса провайдера и т. Д. ... он очень хороший ... но все еще очень хардкорный и т. Д. Избыток для сайтов с простым средним значением, IMO.

Так что лично я бы использовал некоторый простой пользовательский код для обработки постоянства членства для большинства сайтов среднего уровня.

Это переходит ко второму вопросу: OpenId. Воспользуйтесь DotNetOpenAuth .NET Framework Эндрю Арнотта -> буквально Kicks Serious Ass (tm). Использование этого не зависит от того, КАК вы сохраняете данные о членстве пользователя в хранилище. То есть. если вы продолжите и используете поставщика членства Sql Server + ASP.NET, вы все равно можете (и должны) использовать DotNetOpenAuth. Если у вас есть простой, нестандартный способ сохранения сведений о пользователе в базе данных (что я и делаю), вы все равно можете использовать DotNetOpenAuth - они не зависят друг от друга.

Так что, IMO, не используйте слишком сложный материал ASP.NET Membership + Sql Server, а просто одну или две таблицы, чтобы сохранить свои собственные данные пользователя. Затем вы ДОЛЖНЫ использовать DotNetOpenAuth для любого материала OpenId (StackOverflow использует DotNetOpenAuth для обработки своего входа в OpenId).

Удачи:)

(Я уверен, что мои мнения провайдера членства ASP.NET + Sql Server, чтобы сохранить эту информацию, приведут сюда нескольких человек к ярости).

Answer 2

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

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

Answer 3

Посмотрите, что происходит с NerdDinner . Они недавно (6 месяцев назад) интегрировались с OpenID, с Google, Yahoo в качестве рекомендуемых поставщиков. Они по-прежнему разрешают все свои «родные» логины. Вот пример сайта, позволяющего пользователю проходить аутентификацию различными способами.

Если вы сможете отразить некоторые их функции, вы сможете использовать Facebook, OpenAuth и т. Д. Большим преимуществом является то, что он уже реализован в ASP.NET MVC, и вам просто нужно позаимствовать некоторые этой реализации.

Answer 4

Вот вариант, который я успешно использую.

По сути, у вас есть один пользователь, который может быть аутентифицирован несколькими способами.

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

Когда пользователь аутентифицируется с помощью OpenID, Facebook и т. Д., Сопоставьте этот логин с таблицей, которая соответствует конкретному методу входа и идентификатору с идентификацией Forms, и просто задайте пользователю набор данных как зарегистрированный с его каноническим именем пользователя Членства. 1007 *

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

Если пользователь хочет также иметь прямой вход в систему, просто используйте стандартные механизмы сброса пароля провайдера членства и предоставьте им один.

Короче говоря: пока воспользуйтесь встроенным механизмом. Это не мешает вам делать то, что вы хотите сделать.

Answer 5

Недавно представленный SimpleMembershipProvider решает многие проблемы со старым членством asp.net. А именно простота использования и контроля над схемой пользовательских таблиц. Это должно стать отправной точкой для любых новых приложений (по состоянию на 11/2012).

См. Ссылку ниже для ознакомления с учебником SimpleMembershipProvider, а также приличную историю членства в asp.net.

http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx