Почему я должен использовать модель безопасности членства ASP.NET?

Question

Я обновляю свой веб-сайт в данный момент и считаю, что если я хочу обновить свой логин / режим безопасности, сейчас самое подходящее время.

Я просмотрел модель членства, которая включена в ASP.NET, но я не уверен, что она принесет какую-либо пользу, кроме того, что знакома другим разработчикам .NET.

Кажется, что для этого достаточно документации, но мало дискуссий о том, почему это стоит усилий.

Кто-нибудь может пролить свет на это?

Answer 1

Я вижу небольшую выгоду от использования членства для большого сайта. Это было продано как «решение» для аутентификации ASP.Net. Однако на самом деле похоже, что Microsoft просто пытается позиционировать старый продукт Membership Server как нечто такое, в чем вдруг все нуждаются.

Я работал на Membership Server в Msft около 10 лет назад. Также был ведущим разработчиком на shop.microsoft.com, и я могу сказать, что на этом сайте мы не использовали никаких внутренних серверных продуктов - ни коммерческий сервер, ни сервер членства. Не уверен, как они это делают сейчас - но я думаю, что общее мнение на тот момент заключалось в том, что пакеты такого типа обычно мешали тому, что мы пытались сделать.

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

Что я действительно не понимаю, так это то, что почти каждая книга ASP.Net выдвигает это как единственный способ сделать это, а не как один из способов сделать это.

Answer 2

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

Если вам нравится конфигурация XML, строки со слабым типом для ролей, небезопасные по умолчанию, случайные файлы web.config, засоренные в ваших каталогах вместо чистого интерфейса маркеров на ваших классах страниц, чтобы сказать «не требуется учетная запись», несколько попаданий в базу данных для одного входа в систему пользовательские объекты, которые не загружены из вашего текущего ObjectContext / DataContext и возможность менять провайдеров на лету (ау, кто это использует ?!), выбирают встроенные.

Если нет, создайте свой собственный, но если вы это сделаете, убедитесь, что вы сохранили зашифрованные / соленые хеш ваших паролей, и сделайте правильный зашифрованный cookie, пожалуйста.

[Обновлено для отражения отзывов в комментариях]

Answer 3

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

Мы используем встроенную модель провайдера членства и ролей на нашем сайте, и она работает очень хорошо ... нам пришлось писать собственные классы провайдеров, поскольку мы используем другое хранилище резервных копий для данных (мы используем Microsoft Dynamics CRM ), но эти классы довольно просты и хорошо документированы. Проделав эту небольшую работу заранее, теперь мы можем использовать классы Membership и Roles в коде, а также различные серверные элементы управления, связанные с логином, на наших страницах.

Есть ли другая альтернатива, которую вы рассматриваете?

Answer 4

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

Answer 5

Это просто для того, чтобы вам не пришлось бросать свои собственные.

Answer 6

Маршрут членства работает хорошо, НО есть один фатальный недостаток, и я не виню в этом Microsoft.

Internet Explorer - единственный браузер, который правильно удаляет кеш аутентификации.

Вы можете закрыть браузер Firefox, открыть его, а затем восстановить последний сеанс и вернуться обратно на «защищенный» веб-сайт без входа в систему. В Chrome есть похожие проблемы и все, что Mac делает то же самое.

IE имеет вызов javascript, который обрабатывает это правильно: document.execCommand ("ClearAuthenticationCache", "false");

Не работает ни с одним другим браузером. Если вы используете это, вам нужно заставить пользователей использовать IE.

Answer 7

Я думаю, что неотъемлемой чертой членства, роли и профиля ASP.NET является то, что он использует модель поставщика. Если вы не довольны тем, как оно есть, нетрудно выкинуть свое из базовых классов. Если вы посмотрите на codeplex.com, вы можете найти, вероятно, дюжину или более пользовательских провайдеров, написанных людьми. Я написал один для базы данных SQLite несколько лет назад.

Answer 8

Если вы когда-нибудь захотите перенести свой сайт на любое уже созданное программное обеспечение портала, например, на Community Server или DotNetNuke, с помощью провайдера членства, вы сможете легко выполнить миграцию. Вы даже можете использовать существующую базу данных, и вам не придется внедрять новые.

Answer 9

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