Должен ли я использовать членство для этой необычной системы учетных записей

Question

Мой сайт asp.net mvc нуждается в какой-то авторизации, но он несколько отличается от обычной концепции пользователей и, следовательно, членства. На самом деле он будет использоваться больше для предпочтений, чем для аутентификации. Учетные записи без каких-либо паролей должны быть возможны (и изначально будут единственным типом), и учетная запись также может использоваться несколькими пользователями одновременно. В зависимости от группы пользователей может быть, например, что все пользователи определенного региона получают общую учетную запись. Это решение клиента (отдела маркетинга) и не подлежит обсуждению.

Определенная целевая страница принимает (только) идентификатор пользователя в URL-адресе, который будет загружать учетную запись, с которой, в свою очередь, связаны некоторые настройки, которые можно использовать на остальной части сайта. Если пользователь не запускается с целевой страницы или отправленный accountId не соответствует записи в системе, ему / ей будет назначена учетная запись по умолчанию, которая имеет настройки по умолчанию.

Я думал не изобретать велосипед (кто-то должен найти новое выражение для этого) и использовать систему членства asp.net. Но вся система основана на необходимых паролях, электронной почте и отдельных сеансах для пользователя, и это все, что я не могу предоставить. Поскольку ситуация немного нестандартная, я подумал, что будет создан пользовательский MembershipProvider и т. Д. Но, похоже, суть этого унаследована от обычных классов Членства. Все методы этих классов требуют того, что мне не нужно.

Любые предложения

Answer 1

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

Имеют 2 различных пользовательских элемента управления: 1 для «Подтвержденного входа в систему с паролем» и один для «Совместного использования учетной записи без пароля», каждый из которых использует Login-членство, но последний должен иметь бит, установленный в поле участника, который говорит «Public». Account = True / 1 "

Удачи, похоже на веселый проект, было бы здорово увидеть результат;)

Кстати, вам не нужно делиться сессией, или вы могли бы просто сохранить сессию в базе данных и сопоставить сессию пользователю вместо куки, может работать?

---

По запросу я подробно остановлюсь на различных пользовательских элементах управления. Вкратце, у меня будет 2 элемента управления, один из которых может называться GlobalLogin, а другой - UserLogin, где GlobalLogin отображает форму, которая имеет только имя пользователя. При отправке это вызовет функцию, которая использует, как я уже говорил ранее, функцию, которая вызывает метод Validate в поставщик членства, с предварительно установленным паролем.

В качестве отражения рассмотрим всех пользователей «Не вошли в систему с паролем» как анонимных и обращайтесь с ними одинаково, единственное отличие состоит в том, что они могут получить доступ к пользовательским областям. Этот элемент управления также должен проверить, что определенное поле в базе данных установлено, например, поле «Разрешить глобально используемую учетную запись без пароля», где в этом случае бит / логическое значение должно быть истинным, чтобы этот логин был принят.

Теперь перейдем к другой части, элементу управления, который обрабатывает учетные записи, защищенные паролем, для этого требуются имя пользователя и пароль, и это вызывает проверку с этими настройками. Теперь помните, что при входе с паролем вы можете изменить свой пароль, это НЕ ДОЛЖНО быть возможным с глобальной учетной записью, потому что тогда ваш глобальный пароль не будет работать:)

Answer 2

Подробную информацию о поставщике членства можно получить по адресу http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx.. В основном вам необходимо создать нового поставщика, или извлечь его из существующего, и перегрузить метод ValidateUser, чтобы всегда возвращать true.