*не* использование поставщика членства asp.net плохая идея?
Это обычно - действительно плохая идея не использовать встроенного поставщика членства asp.net?
Я всегда прокручивал свое собственное для моих (общедоступных) приложений asp.net, и действительно не имел никаких проблем при этом. Это работает и, кажется, избегает слоя сложности. Мои потребности являются довольно главными: однажды установка, пользователь должен использовать адрес электронной почты и пароль для входа в систему, если они забудут это, то это будет послано по электронной почте назад им (новый). После того, как установка там мало, который должен быть сделан к каждой учетной записи пользователя, но я действительно должен снабдить несколько дополнительных полей каждым пользователем (полное имя, телефон и несколько других полей и т.д.). Число пользователей, которые потребовали данных для входа в систему, является небольшим (обычно просто администратор и несколько резервных копий), и все остальные используют неаутентифицируемый сайт.
Каковы большие преимущества, которые я мог бы пропускать путем пропуска функциональности поставщика членства asp.net?
7 ответов
Использование собственной системы аутентификации никогда никогда не является хорошей идеей. Существует так много способов ошибиться, что кажется работающим при тестировании, пока год спустя вы не узнаете, что ваш сайт был взломан шесть месяцев назад.
Всегда максимально полагайтесь на код безопасности, предоставленный для вас вашей платформой, будь то asp.net или что-то еще. Сделайте это, и система будет поддерживаться поставщиком с большим количеством развертываний, так что ошибки можно будет легче найти и исправить, и даже если у вас есть проблема, вы можете возложить вину на поставщика, когда ваш босс приходит с просьбой об этом. Не говоря уже о том, что как только вы впервые воспользуетесь решением вашего поставщика, дополнительные развертывания будут выполняться быстрее. Это правильный способ сделать это.
Провайдер членства в ASP.Net далек от совершенства, но я обещаю вам, что предпочтительнее создавать его с нуля.
Членство - это нечто большее, чем просто членство (логин, адрес электронной почты, пароль и связанные с ним функции). Aspnet отделяет членство от профиля, и они могут быть интегрированы. Профиль - это все, что вы называете «дополнительными полями». У вас может быть анонимный профиль с некоторыми настройками, даже если у вас нет членства. Например, пользователь может настроить предпочтения, вернуться на сайт и по-прежнему иметь их, но все равно не зарегистрироваться. Затем, когда вы регистрируетесь, анонимный профиль можно перенести и связать с вашим новым членством.
Это то, чего вы в основном упускаете, когда пропускаете его.
Кроме того, если вы решите использовать встроенные или сторонние элементы управления, которые используют членство и профили, вы тоже этого не заметите.
Вы можете реализовать поставщика вместо того, чтобы сразу отказываться от модели поставщика.
Преимущества модели поставщика описаны здесь , но вкратце:
Некоторые готовые веб-элементы управления созданы для использования модели поставщика членства, например, Элемент управления / представление входа в систему и Мастер создания пользователя. Таким образом, вы упускаете одноэтапную конфигурацию для входа в панель управления для всех ваших страниц без написания кода.
Провайдеры можно поменять местами, просто изменив файл web.config. Я не говорю, что вы не можете написать свой собственный вход в систему, чтобы сделать то же самое, но вы можете легко написать собственный поставщик в какой-то момент в будущем и включить его в свое приложение, не меняя ничего в приложении.
Предоставляются все основы. У поставщиков членства по умолчанию есть извлечение пароля, блокировка учетной записи, несколько методов шифрования паролей, конфигурация правил ограничения допустимого пароля и управление пользователями - и все это "из коробки". Простое использование только этого значительно сокращает время установки для большинства людей, запускающих приложение ASP.Net с нуля.
Большой компонент вашего приложения уже проверен. Вам не нужно беспокоиться об отладке всего собственного кода аутентификации! Это означает, что когда есть ошибки, вы часто получаете исправления до того, как сайт ломается, и у вас есть возможность снять вину, если нет.
Вы можете получить некоторое представление из этих других популярных вопросов:
Какие схемы аутентификации и авторизации вы используете - и почему?
Microsoft Membership Provider Vs Custom Provider Vs Complete Custom Login System
Если у вас есть решение, которое хорошо работает , придерживайтесь его. «Если что-то работает, не чините» и все такое. В противном случае учтите, что API членства имеет в тысячи раз больше часов программиста, часов контроля качества и часов пользователя, чем все, что вы могли бы придумать самостоятельно.
В вашем случае аутентифицированные пользователи - это исключение, а не норма, поэтому, вероятно, не помешает создать свою собственную систему.
Одна вещь, которую предоставляет .net - это защита от атак перебором, в случае, если кто-то попытается перебрать пароль администратора, учетная запись администратора будет заблокирована.
Как вы сохраняете пароли пользователей? Если вы сохраняете их в виде обычного текста, это большой риск. Одним из преимуществ системы членства ASP.NET является то, что она шифрует пароли с помощью хэширования, причем "из коробки".