В настоящий момент я обновляю свой сайт и рисую, что если я обновляю свой режим входа в систему, теперь самое подходящее время.
Я просмотрел модель Membership, которая включена в ASP.NET, но я не уверен, что она предоставит вам какую-либо выгоду, не знакомая другим разработчикам .NET.
Похоже, для этого достаточно документации, но мало обсуждается, почему это стоит усилий.
Может ли кто-нибудь пролить свет на это?
Я вижу небольшую выгоду от использования членства для большого сайта. Это было реализовано как "решение для аутентификации ASP.Net". Однако, действительно, похоже, что Microsoft просто пытается позиционировать старый продукт Membership Server как нечто необходимое, что все внезапно нуждаются.
Я работал на Memberhip Server в Msft около 10 лет назад. Был также ведущим разработчиком на сайте shop.microsoft.com, и могу сказать, что на этом сайте мы не использовали внутренние серверные продукты, а не сервер коммерции, а не членский сервер. Не уверен, как они это делают сейчас, но я думаю, что общий консенсус в этот момент заключался в том, что эти типы пакетов обычно мешали тому, что мы пытались сделать.
Это может быть полезно для небольшого сайта, или если у вас ограниченные ресурсы... т.е. несколько сотен пользователей для интрасети отдела или небольшой компании, где вы не хотите вкладывать много времени или ресурсов. Чем больше я смотрю на него, тем больше он кажется совершенно неуместным для более крупных пользовательских веб-сайтов.
То, что я действительно не понимаю, - это то, как почти каждая книга ASP.Net, похоже, делает это единственным способом сделать это, а не одним из способов сделать это.
Я написал свое собственное после прочтения всех хранимых процедур в поставщике членства ASP.NET. Это не сложно, и у вас гораздо больше контроля в конце дня.
Если вам нравится конфигурация XML, слабо типизированные строки для ролей, по умолчанию небезопасные, случайные файлы web.config засоряются через ваши каталоги, а не чистый интерфейс маркера на ваших классах страниц, чтобы сказать "нет учетной записи", несколько запросов к базе данных для единого входа в систему, пользовательские объекты, которые не загружаются из вашего текущего объекта ObjectContext/DataContext, и возможность менять провайдеров "на лету" (woo hoo, кто использует это?!) для встроенного.
Если нет, создайте свой собственный, но если вы это сделаете, убедитесь, что вы храните зашифрованный/соленый хэш ваших паролей и делаете правильный зашифрованный файл cookie.
[Обновлено, чтобы отразить отзывы в комментариях]
Если вы не единственный человек, который когда-либо будет работать на этом конкретном сайте, я думаю, что тот факт, что он знаком с разработчиками .NET, является хорошей причиной для перехода по встроенному маршруту членства. Другие разработчики с опытом работы с ASP.NET могут быстро перейти на проект и быстро перейти на вашу модель аутентификации/авторизации вашего сайта.
Мы используем встроенную модель поставщика членства и роли на нашем сайте, и она работает очень хорошо... нам пришлось писать собственные классы поставщиков, поскольку мы используем другое хранилище данных для хранения данных (мы используем Microsoft Dynamics CRM), но эти классы довольно просты и хорошо документированы. Выполняя эту работу, мы теперь можем использовать классы Membership и Roles в коде, а также различные элементы управления, связанные с подключением к серверу на наших страницах.
Есть ли другая альтернатива, которую вы рассматриваете?
Единственное, что я действительно ненавижу в членском пакете, который поставляется с .Net, - это тот факт, что идентификатор пользователя - это идентификатор GUID, а не автоинкрементный идентификатор. Я знаю, что есть бонусы к использованию GUID, но интеграция его в уже существующие системы или модули может быть болью.
Это просто так, что вам не нужно сворачивать самостоятельно.
Это значение состоит в том, что это простая в использовании готовая встроенная структура безопасности на основе ролей. Если вы уже создали свою собственную инфраструктуру, а миграция не является тривиальной, она может оказаться нецелесообразной. Но одним из преимуществ миграции является то, что вы могли бы устранить много кода приложения и заменить его кодом.
Если вы когда-либо захотите перенести свой сайт на любое уже сделанное программное обеспечение портала - например, на Community Server или DotNetNuke, используя провайдер членства, можно легко переносить. Вы даже можете использовать существующую базу данных и не использовать новые.
Я думаю, что привлекательной особенностью членства, роли и профиля ASP.NET является то, что он использует модель поставщика. Если вы недовольны тем, как это делается, нетрудно сворачивать свои собственные из базовых классов. Если вы посмотрите на codeplex.com, вы можете найти дюжину или более пользовательских поставщиков, которые люди написали. Я написал один для базы данных SQLite несколько лет назад.
Маршрут членства работает хорошо, но есть один фатальный недостаток, и я не обвиняю Microsoft в этом.
Internet Explorer - единственный браузер, который правильно использует кеш аутентификации.
Вы можете закрыть браузер Firefox, открыть его, а затем восстановить последний сеанс и вернуться обратно на свой "безопасный" веб-сайт без входа в систему. У Chrome есть аналогичные проблемы, и все, что делает Mac, делает то же самое.
У IE есть javascript-вызов, который обрабатывает это правильно: document.execCommand( "ClearAuthenticationCache", "false" );
Он не работает ни с каким другим браузером. Если вы используете это, вам нужно заставить пользователей использовать IE.