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

Question

Является ли вообще действительно плохой идеей не использовать встроенного поставщика членства asp.net?

Я всегда катал свои собственные приложения для asp.net (общедоступные), и у меня действительно не было проблем с этим. Это работает, и, кажется, избежать уровня сложности. Мои потребности довольно просты: после установки пользователь должен использовать адрес электронной почты и пароль для входа в систему, если они его забудут, он будет отправлен обратно по электронной почте (новый). После настройки мало что нужно сделать для каждой учетной записи пользователя, но мне нужно хранить несколько дополнительных полей для каждого пользователя (полное имя, телефон и несколько других полей и т. Д.). Количество пользователей, которым требуются учетные данные для входа, невелико (обычно это просто администратор и несколько резервных копий), и все остальные используют сайт без проверки подлинности.

Каковы большие преимущества, которые я мог бы упустить, пропуская функциональность поставщика членства asp.net?

Answer 1

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

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

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

Answer 2

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

1. Некоторые готовые веб-элементы управления созданы для использования модели поставщика членства, например, Контроль входа в систему / просмотр и Мастер создания пользователя. Таким образом, вы упускаете одношаговую конфигурацию для наличия панели входа в систему для всех ваших страниц без написания кода.

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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

Я рекомендую использовать новый материал, потому что:

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

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

Answer 4

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

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

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

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

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

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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