Членство в ASP.NET: быть или не быть? - PullRequest
4 голосов
/ 21 июня 2010

Я обдумываю, как мне следует реализовать авторизацию и аутентификацию с ASP.NET и MVC2.Давайте обратимся к этому как к пользовательской системе.

Я видел три типа решений в дикой природе:

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

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

Если вы используете членство в ASP.NET

  • Как выглядит схема вашей базы данных?Как вы создаете внешние отношения с пользователями членства в ASP.NET (например, песни <=> FavoriteSongs (<=> SiteUsers) <=> aspnet_Users)?
  • Почему вы не свернули свои собственные?

Если вы свернули свой собственный

  • Какой уровень абстракции пользовательской системы, если он есть, вы использовали?
  • Почему вы не использовали ASPЧленство в .NET?

Я действительно парализован анализом этих возможностей.Пожалуйста, пинайте меня в правильном направлении от этой липкой паутины членства!Спасибо.

Ответы [ 2 ]

1 голос
/ 21 июня 2010

встроенный провайдер членства уже безопасен и действительно ДЕЙСТВИТЕЛЬНО прост в использовании.Вы можете начать работу со встроенным членством за пару часов.В качестве альтернативы (в зависимости от типа приложения, которое вы создаете) вы также можете проверить, используя OpenID , который используется в StackOverflow.

Кроме того, со встроенным поставщиком членства создание отношенийтак же просто, как использовать «uniqueidentifier», чтобы связать таблицу aspnet_User (я не могу вспомнить точное имя в верхней части моей головы) с соответствующей таблицей.

Я храню все свои «членские» вещи вта же база данных, что и в системе db, и она никогда не управляла мной неправильно.Создание членства "вещи" также легко.Просто запустите aspnet_regsql.exe для базы данных, в которую вы хотите войти в asp.net

Вот еще один вопрос SO в том же ключе.

0 голосов
/ 23 января 2012

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

Я, однако, один из тех, кто рискует, и бросил свой.Я дважды и трижды проверял каждую строку кода на наличие ошибок безопасности, и до сих пор у меня не было исправлено никаких недостатков безопасности с тех пор, как я выпустил 1.0 своей системы аутентификации.В любом случае, моя система аутентификации называется FSCAuth и лицензирована BSD.

  • Какой уровень абстракции пользовательской системы, если таковой имеется, вы использовали?

Я не совсем уверен, что вы имеете в виду.У меня в основном есть один слой, где пользовательские данные извлекаются и записываются в / из базы данных.Один уровень, где FSCAuth фактически имеет дело с файлами cookie и HTTP-аутентификацией.И один слой, где вы говорите FSCAuth, что «эй, эта страница должна быть видна только если текущий пользователь находится в группе администраторов».

Мой класс UserData довольно прост, требуется только 4 поля: Имя пользователя, PasswordHash, UniqueID и Salt.Это то, от чего зависит FSCAuth.Если вам нужно больше полей, вы можете наследовать от класса UserData, и он будет работать точно так же.

  • Почему вы не использовали членство в ASP.NET?

Я обнаружил так много недостатков во встроенной аутентификации ASP.Net

  1. Необходимо написать много кода, если вы хотите использовать что-либо, кроме встроенного провайдера членства
  2. Иногда вам приходится иметь дело с cookie-файлами самостоятельно, что, я бы сказал, опасно
  3. Почти невозможно использовать алгоритм хеширования Blowfish
  4. Несколько циклов в базу данных для каждой загрузки страницы
  5. Сеансы с сохранением состояния (когда пользователь входит в систему, запись помещается в базу данных), что делает его болеетрудно расширить на несколько серверов и, как правило, создает больше ненужных нагрузок на сервер базы данных.
  6. Подробная аутентификация (может видеть электронную почту человека А, но не человека Б) сложнее, чем хотелось бы
  7. GUIDs

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

Что ж, в FSCAuth я по дизайну не учел совсем немного, и, честно говоря, нет способа, которым это подходит для всех ... но его гораздо проще использовать, чем членство в ASP.Net во многих распространенных сценариях.Можно использовать практически любой алгоритм хеширования под солнцем.Один удар по базе данных для аутентификации.Логины без сохранения состояния.Уникальный идентификатор может быть любым, что поместится в строку.И т.д.

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

...