Является ли * не * использование провайдера членства asp.net плохими идеями?

Ответ 1

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

Всегда опирайтесь как можно больше на код безопасности, предоставляемый вашей платформой, будь то asp.net или что-то еще. Сделайте это, и система поддерживается поставщиком с большим количеством развертываний, так что ошибки могут быть найдены и исправлены более легко, и даже если у вас есть проблема, вы можете возложить вину на продавца, когда ваш босс спрашивает об этом. Не говоря уже о том, что как только вы пройдете первый раз с помощью решения вашего поставщика, дополнительные развертывания будут быстрее. Это правильный способ сделать это.

Поставщик членства ASP.Net далек от совершенства, но я обещаю вам, что он предпочтительнее создавать его с нуля.

Ответ 2

Преимущества модели поставщика описаны здесь, но вкратце:

• Определенные готовые webcontrols созданы для использования модели поставщика членства, например Элемент управления/просмотра входа и "Создать пользовательский мастер". Таким образом, вы пропустите 1-ступенчатую конфигурацию для входа в панель управления для всех ваших страниц без написания кода.

• Провайдеры могут быть заменены простым изменением файла web.config. Не говоря о том, что вы не можете писать свой собственный материал для входа, чтобы сделать то же самое, но вы можете легко написать пользовательский провайдер в какой-то момент по дороге и переключить его в свое приложение, не изменяя ничего в приложении.

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

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

Ответ 3

Я согласен с чувства Айенде об этом:

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

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

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

Не путайте MemberhipProvider с FormsAuthentication, на который я по-прежнему регулярно полагаюсь на свои приложения. Это механизм, который заботится о переносе токена аутентификации пользователя в куки файл и передачи между клиентом и сервером. Насколько я знаю, нет ничего плохого в FormsAuthentication, и я бы не предложил его изобретать.

Если вы не хотите внедрять десятки Методы MembershipProvider, RoleProviderMethods и методы ProfileProvider, тогда просто реализуйте IPrincipal и IIdentity и просто сделайте то, что вам нужно сделать. Вот пример получения этих двух интерфейсов, работающих с FormsAuthentication, который тривиален.

Кроме того, имейте в виду, что вам нужно быть умным для хранения учетных данных ваших пользователей. SqlMembershipProvider делает, по крайней мере, может хранить хешированные соленые пароли. Убедитесь, что вы хотя бы поступили так же. Вот хороший фрагмент кода, чтобы помочь в этом. Обратите внимание на используемый алгоритм медленного хэширования. Не употребляйте наркотики.

обновление (2013-12-16)

Все изменилось в ASP.net, так как я написал это. Идентификатор ASP.NET ранее заменяет функции членства.

Моя рекомендация - использовать новый материал, потому что:

• Вы можете реализовать различные интерфейсы, чтобы составить решение, соответствующее вашим потребностям. Это означает, что вы можете реализовать те части, которые хотите, и игнорировать те части, которые у вас нет.
• Вы можете полностью изменить, где/как вы храните идентификационные данные, сохраняя при этом реализацию по умолчанию, контролирующую хеширование паролей.
• Функции OAuth и OpenID.
• Вы можете использовать одну и ту же систему в любых рамках, построенных на OWIN.

API немного сложнее, чем раньше, но более гибкий.

Ответ 4

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

Ответ 5

Вы можете получить представление о других популярных вопросах:

Какие схемы аутентификации и авторизации вы используете - и почему?

Поставщик членства в Microsoft и пользовательский поставщик Vs Полная система пользовательского входа

Кто-нибудь использует членство в ASP.NET?

Альтернативы членству .Net

Ответ 6

Существует больше членства, а затем просто членство (логин, электронная почта, пароль и функциональность вокруг него). Aspnet отделяет членство от профиля, и они могут быть интегрированы. Профиль - это все, что вы называете "дополнительными полями". У вас может быть анонимный профиль с некоторой настройкой, даже если у вас нет членства. Например, пользователь может настроить настройки, вернуться на сайт и все еще иметь их, но все равно не регистрируется. Затем, когда вы регистрируетесь, анонимный профиль может быть перенесен и связан с вашим новым членством.

Вот что вы в основном пропустите, когда пропустите его.

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

Вы можете внедрить поставщика, а не сразу удалить модель поставщика.

Ответ 7

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

Одна вещь .net обеспечивает защиту от грубой силы, на случай, если кто-то попытается перенаправить пароль администратора, учетная запись администратора будет заблокирована.

Ответ 8

Я чувствую вашу боль со сложностями встроенной аутентификации ASP.Net. Я устал от необходимости писать код для функций, которые я никогда не буду использовать. (а также оставляя кучу функций NotImplemented). Я также устал от трудностей использования чего-то другого, кроме GUID и имеющего несколько обращений к базам данных на каждой загрузке страницы (только для проверки подлинности)... Итак, я откатился сам. Он назвал FSCAuth и лицензирован BSD.

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

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

Ответ 9

Как вы сохраняете пароли пользователей? Если вы сохраняете простой текст, это серьезный риск. Одним из преимуществ системы членства ASP.NET является то, что она шифрует пароли путем хеширования из коробки.