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

Ответ 1

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

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

Затем вы переходите к своему второму вопросу: OpenId. Используйте Andrew Arnott DotNetOpenAuth.NET framework → it litterally 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, чтобы сохранить эту информацию, приведут к тому, что несколько человек будут придирчивы, здесь).

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

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

Ответ 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