Я создаю новый веб-сайт, и друг предлагает мне использовать членство asp.net для процесса аутентификации (логин, регистрация, восстановление пароля и т.д.).
Я видел, что все хранится в XML файле.
Я хотел бы знать, какие плюсы и минусы используют членство, а не строить что-то с нуля.
Решение для входа в MS состоит из нескольких частей.
Аутентификация форм. Это создает безопасный файл cookie, в котором говорится: "Я аутентифицирован!". по каждому запросу. Без этого пользователям придется регистрироваться на каждой странице.
Членство. Таким образом вы храните своих пользователей и их пароли и проверяете учетные данные пользователя. Есть несколько способов приблизиться к этому:
Создание пользовательского элемента MembershipProvider - вы можете наследовать от MembershipProvider, чтобы настроить, где и как вы храните свои данные.
Создание собственной схемы аутентификации
Роли. Роли управляют тем, что пользователи могут выполнять с помощью механизма авторизации предоставленного web.config, а также работает с обрезкой безопасности на карте сайта.
Использование SqlRoleProvider - Microsoft предоставляет вам базу данных для хранения ролей
Создание настраиваемого RoleProvider - вы можете наследовать от RoleProvider, чтобы настроить, где и как вы храните свои данные.
Создание собственной схемы аутентификации
Важно отметить, что поставщики членства и роли могут быть выбраны или настроены независимо друг от друга. Я бы лично рекомендовал использовать SqlMembershipProvider, если вы можете и оцениваете свои параметры для поставщика ролей.
Мне не нравится использовать Memberhip Provider.
Это используется, когда сценарий является "стандартным", но в случаях, когда вам нужны дополнительные пользовательские правила, я думаю, что это не работает. Появляются "обходные пути".
И не нужно хранить в XML, существует другое решение (база данных, для exmaple).
Минусы:
Ваше предпочтительное хранилище данных может не полностью поддерживаться из коробки
Это может не соответствовать вашим текущим или будущим требованиям.
Возможно, вы не в полной мере понимаете тонкости того, как это работает (над чем-то, что вы сами создали)
Плюсы:
Лично..., если это серьезный проект, я бы сделал свой собственный (но, конечно же, проверку подлинности форм). По моему опыту, многие из этих функций "из коробки" из MS довольно наполовину.
Самое приятное в членстве ASP.Net заключается в том, что вы можете использовать столько или меньше, сколько хотите - вы можете хранить пользовательские данные в различных формах (как упоминалось в других публикациях), или вы можете просто использовать членство ASP.Net для обрабатывать авторизацию сеанса и защиту страниц.
Например, вы можете запустить весь hog и использовать элемент управления входами, конец SQLMembershipProvider и просто позволить членству ASP.Net сделать все от конца до конца.
Или вы можете хранить свои собственные имена пользователей и пароли в своей собственной таблице базы данных, самостоятельно аутентифицировать предоставленные вами данные, а затем просто использовать "FormsAuthentication.RedirectFromLoginPage()", чтобы сообщить членству в ASP.Net, что пользователь аутентифицирован, и Членство ASP.Net контролирует доступ к страницам.
Членство в ASP.Net проверено и проверено, оно используется тысячами сайтов внутри и вне Microsoft, поэтому вы знаете, что код работает и работает хорошо. Если есть проблема, тогда есть много реализаций, которые найдут ее. У вашего собственного подхода есть только один пользователь...
Собственно, все не сохраняется в XML файле. Вы можете хранить данные о членстве несколькими способами, включая базу данных.
Вы также можете использовать роуминг/членскую библиотеку ASP.NET в качестве отправной точки для сворачивания своих собственных. Есть несколько учебников по этому поводу вокруг межсетевых экранов.
Плюсы с использованием встроенных функций состоят в том, что членство в ASP.NET gui-control более или менее "просто работает"..;)
По-моему, поставщики членства в .NET - отличный способ пойти независимо. Я написал немало крупных приложений, использующих их. Если ваша архитектура хороша, довольно просто добавить функциональность и изменить данные в будущих выпусках.
Здесь немного контекста для оформления моих ответов. Решения для членства/роли/профиля в .NET состоят из двух частей: структуры и поставщиков. Структура состоит из методов и информации, с которыми будет взаимодействовать ваша программа. Поставщики определяют, как будут храниться данные.
Я считаю, что структура отличная. Существует не так много, что вы не можете сделать, независимо от того, как вы хотите взаимодействовать с ним. Реализации по умолчанию дают вам много свободного. Любое отсутствие функциональности дополнительно смягчается как con, если вы используете хорошие методы кодирования. Посмотрите стартовое приложение ASP.NET MVC для отличного примера обертывания структуры членства.
Данные никогда не выглядят так, как вы хотите, но ничего не можете обойти. Сначала, как говорили люди, есть множество поставщиков, поставляемых с .NET. И это также означает, что внедрение вашего собственного провайдера вступает в игру. Обычно мы начинаем с подкласса SqlMembershipProvider. Если что-то не работает так, как мы хотим, мы переопределяем его. И изменение таблиц данных в более позднее время, если необходимо, не является ужасно трудным.
Использование того, что уже существует, всегда, кажется, позволяет быстро развиваться и адаптироваться по мере необходимости. По правде говоря, изменения в этом коде происходят нечасто. Использование решения Microsoft вначале может не привести к самой красивой работе, но она быстро выполняет задание и позволяет перейти к решению важных проблем.