Хранение дополнительных пользовательских данных в MembershipProvider / FormsAuthenticationTicket - PullRequest
3 голосов
/ 02 августа 2010

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

Мой вопрос: как мне хранить дополнительные пользовательские данные вместе в FormsAuthenticationTicket? Я хочу сохранить несколько вещей, которые никогда не изменятся, например, их UserId, Имя / Фамилия и Страна. Я начал изучать создание FormsAuthenticationTicket с UserData, но быстро запутался. Как мне хранить несколько вещей в этих UserData, и как мне легко читать эти данные обратно на каждой странице ASP.NET MVC2. Я нашел много сэмплов, но ни один из них не показался мне настолько хорошим с точки зрения MVC2. Должен быть простой способ сделать это.

Не имеет смысла считывать идентификатор пользователя, имя / фамилию и страну из базы данных по каждому запросу, потому что он никогда не изменится. Кроме того, хотя я хочу, чтобы пользователь входил в систему, используя свою электронную почту, я хотел бы сохранить свой UserId в файле cookie для аутентификации, чтобы его можно было использовать практически в каждом запросе к базе данных, связанной с пользователем, а не в электронной почте (поскольку во всех таблицах пользовательские данные хранятся вместе с UserId, а не электронной почтой, поскольку технически электронная почта может быть изменена - я уже понял, что это нужно, когда дело доходит до MembershipProvider).

Каков наилучший способ хранения дополнительных пользовательских данных, подобных этому, в ASP.NET MVC2?

Ответы [ 7 ]

4 голосов
/ 03 августа 2010

В этом посте показаны (помимо прочего) подробности хранения в FormsAuthenticationTicket.UserData и чтения его из базового контроллера. http://www.west -wind.com / блог / сообщений / 899303.aspx

Как кто-то предложил выше, простой класс данных, который содержит всю необходимую информацию, и пара методов сериализации / десериализации выполнят эту работу.

    public class UserState
    {
        public int Id { get; set; }

        public Guid ActivationId { get; set; }
        public string UserName { get; set; }
        public string Email { get; set; }
        public bool IsAdmin { get; set; }

        // Serialize    
        public override string ToString()
        {
            JavaScriptSerializer serializer = new JavaScriptSerializer();
            string result = serializer.Serialize(this);
            return result;
        }

        // Deserialize
        public static UserState FromString(string text)
        {
            JavaScriptSerializer serializer = new JavaScriptSerializer();
            return serializer.Deserialize<UserState>(text);
        }
    }
}
2 голосов
/ 02 августа 2010

Файл cookie FormsAuthenticationTicket имеет свойство UserData, в котором вы можете хранить все, что захотите. Я добавляю сюда графы сериализованных объектов JSON для кеширования связанных с пользователем вещей, таких как фамилия, имя или дополнительная информация о роли.

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

1 голос
/ 02 августа 2010

Как насчет использования Session для этого?

1 голос
/ 02 августа 2010

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

НТН.

0 голосов
/ 02 августа 2010

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

0 голосов
/ 02 августа 2010

Профиль - это лучший способ хранения пользовательских пользовательских данных.Все, что вам нужно сделать, это создать поля на странице web.config, а затем ссылаться на них, как на переменную состояния сеанса.Состояние сеанса подходит для данных, которые являются постоянными в течение 1 сеанса (отсюда и название).

Web.Config:

    <profile>
        <properties>
            <add name="DepartmentNumber"/>
        </properties>
    </profile>

Сохранить в профиль:

ProfileCommon newProf = Profile.GetProfile(username);
                newProf.DepartmentNumber = "12";   //Or whatever string data you have.
                newProf.Save();

Справка:

String departmentNumber = Profile.DepartmentNumber;    //Data is stored as String.
0 голосов
/ 02 августа 2010

Я бы использовал Профиль для хранения пользовательской информации, ведь это то, для чего она была разработана:)

ASP.Net Profile

А есливам нужно хранить информацию в более структурированном формате SQL, использовать Провайдер настраиваемого профиля

В своем настраиваемом профиле вы можете реализовать кэширование, и я уверен, что вы можете уменьшить его доогромное количество пользователей.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...