Мне нужно было настроить систему быстрого членства для клиента, у них были некоторые требования, которые не позволяли мне использовать встроенную систему сразу же, ни время, чтобы построить то, что они хотели. У меня есть планы в конечном итоге развернуть полную систему управления членством, но, как и вы, мне что-то было нужно сейчас. Я пошел по следующему плану, который, в конечном итоге, позволит мне заменить встроенных провайдеров на свои собственные - временные ограничения и сроки отстой:
У меня есть своя личная таблица пользователей (PT) - MembershipId, UserName, Email, лишняя информация профиля. Это то, что приложение использует для любой пользовательской информации. Это класс, его можно кэшировать, сохранять в контексте http, cookie - однако вы хотите обрабатывать информацию о пользователе.
Затем я настроил SqlProfileProvider для аутентификации, авторизации и ролей. Я не использую провайдера профилей (даже для тривиальных настроек), потому что это боль в MVC. Я не внес никаких изменений во встроенные провайдеры. Это то, что я использую для аутентификации и авторизации.
При создании пользователя мой код выполняет следующие действия:
- Проверьте PT на имя пользователя и адрес электронной почты, согласно моим правилам
- Создать Guid - MembershipId
- Создать MembershipUser, MembershipId - это имя пользователя (адрес электронной почты не имеет значения и не используется), а также пароль пользователя, вопрос и ответ и т. Д.
- Создайте пользователя в PT со значениями профиля и используйте MembershipId в качестве PrimaryKey.
При входе в систему я получаю идентификатор членства от PT, проверяю соответствие членству с помощью идентификатора членства и пароля, и все готово.
При удалении пользователя я делаю следующее:
- Проверьте PT для пользователя, убедитесь, что я могу / должен удалить
- Получить MemberShipId
- Использовать транзакцию
- Удалить из PT
- User Membership.DeleteUser (MembershipId, true) - это гарантирует, что пользователь будет удален из членства и других таблиц aspnet_
- * совершить 1037 *
И все работает как положено:)
Несколько вещей:
User.Identity.Name будет идентификатором членства (Guid). Это используется для входа в систему и управления ролями. Мой PT - это то место, где хранится информация пользователя (сохранить пароль). Я могу изменять имена пользователей, адреса электронной почты и т. Д., Не влияя на членство или роли, потому что членство основано на PrimaryKey от PT.
Для входа в систему требуется дополнительное попадание в БД, потому что вам нужно запросить PT, чтобы получить для проверки членский идентификатор (можно кэшировать).
Встроенная система аутентификации действительно тяжелая - если вы посмотрите на sprocs, вы увидите все циклы, через которые проходит проверка пользователя. Я бы порекомендовал в конце концов уйти от этого. Но в трудном положении это хорошо работает - и если у вас нет миллионов пользователей, я не думаю, что это будет проблемой.
Я не рассматривал OpenId, и я не уверен, как бы вы его интегрировали, хотя я думаю, что вы, вероятно, могли бы сделать то же самое, что и выше, и вместо того, чтобы проверять действительные учетные данные (после того, как они вернутся проверенной формы OpenId) просто войдите в систему с помощью MembershipId (не проверять членство).
Для меня основным моментом этого было то, что приложение использует пользовательскую модель пользователя, позволяющую изменять имя пользователя, адрес электронной почты, имена и т. Д., Не влияя на аутентификацию и роли. Когда я буду готов перейти к полной системе, я могу изменить ее, не беспокоясь о влиянии на приложение.