Я пытался реализовать пользовательский поставщик членства на основе SQL Server, и одна из моих проблем заключается в том, что membersUserObject имеет ключ GUID. Поскольку я использую существующий идентификатор в качестве ключа к ролям и пользовательским данным, это представляет интересную проблему.
Мне бы хотелось, чтобы ваше мнение о том, какой вариант - или есть ли другой вариант, который я не рассматривал - использовать, если я хочу сохранить свой собственный идентификатор в веб-сеансе без постоянного обращения к базе данных постоянно. Я знаю, что по умолчанию элемент управления входом создает файл cookie проверки подлинности с помощью имени пользователя объекта членства. Итак - я мог бы:
- Реализуйте метод Logging_In элемента управления входом, чтобы вручную добавить мое поле в файл cookie аутентификации
if (Membership.ValidateUser (Login1.UserName, Login1.Password))
{
FormsAuthenticationTicket ticket = новый
FormsAuthenticationTicket (
1,
Login1.UserName,
DateTime.Now,
DateTime.Now.AddMinutes (30),
Login1.RememberMeSet,
"некоторые пользовательские данные хотят хранить в тикете ....", // User-data,
в этом случае роли
FormsAuthentication.FormsCookiePath);
string hash = FormsAuthentication.Encrypt (ticket);
HttpCookie cookie = new HttpCookie (
FormsAuthentication.FormsCookieName,
хэш);
if (ticket.IsPersistent) cookie.Expires = ticket.Expiration;
Response.Cookies.Add (печенье);
Создайте пользовательский объект MembershipUser, который наследуется от MembershipUser и предоставляет мое дополнительное свойство. Мне все равно придется как-то упорствовать (в сеансе? Www.www.)
Создайте пользовательский поставщик профилей, который содержит дополнительное поле и кэш, который находится в сеансе. Это похоже на избыточное количество, хотя для немногих полей я бы кешировал.
Какая лучшая практика здесь? Я прочитал множество статей, и дополнительные данные в бланке форм пока кажутся лучшими.