Лучшая практика для поддержания идентификатора пользователя (MVC) - PullRequest
Новая
       7

Лучшая практика для поддержания идентификатора пользователя (MVC)

6 голосов
/ 13 марта 2012

Я использую FormsAuthentication, но я добавил пользовательский MemberShipProvider для проверки по пользовательской пользовательской таблице.

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

Ранее я использовал переменную сеанса (ASP.NET Webform), но, поскольку я переписываю веб-приложение в MVC, я хотел бы спросить, что обычно считается лучшим подходом для этого.

Является ли переменная сеанса лучшим местом для хранения idUser, или я должен добавить пользовательский "Current.User.Identity", который в дополнение к имени пользователя также содержит публичный идентификатор пользователя ??

Или я должен выбрать совершенно другой подход?

Ответы [ 2 ]

3 голосов
/ 13 марта 2012

У меня был тот же вопрос, когда я реализовал пользовательский поставщик членства для MVC.В итоге я сделал две вещи.Я храню идентификатор пользователя в поле ProviderUserKey объекта MembershipUser.См. provideruserkey .Затем, чтобы ответить на ваш вопрос, да, я создал пользовательский принципал из System.Web.Security.IPrincipal, хотя позже я унаследовал от System.Web.Security.RolePrincipal, поскольку мне требовалась поддержка ролей. 

public class MyPrincipal : RolePrincipal
{
    public Guid Id { get; set; }

    public MyPrincipal(string providerName, IIdentity identity, Guid id) : base(identity)
    {
        Id = id;
    }
}

Обновление: Причина, по которой я не хотел использовать сессию в моем случае, заключается в том, что я отключил его для приложения.Я читал, что основная концепция MVC - это разделение интересов, и это близко моделирует работу сети, которая не имеет состояния.Хотя я не могу вспомнить, где я читал это сейчас, когда я пытаюсь запомнить.Однако я также помню, что читал, что если вы можете устранить сеанс, вы должны это сделать.Это позволит IIS обслуживать одновременные запросы от вашего приложения, а не ждать, пока один запрос завершится (и завершит сеанс пользователя), прежде чем следующий запрос сможет использовать сеанс и отправить свой ответ.Самое большое влияние на это - загрузка содержимого страницы с помощью Ajax.

3 голосов
/ 13 марта 2012

Ваши имена пользователей уникальны? Если это так, нет необходимости поддерживать UserId, поскольку вы можете просто получить пользователя по имени пользователя.

Мои проекты MVC реализовали членство почти так же, как и в традиционных приложениях веб-форм. Я не думаю, что есть какая-либо причина смотреть на них по-разному, если только вы не пытаетесь создать приложение типа REST без состояния. Как вы поддерживали свой UserId в веб-формах? Сессия? Затем используйте сессию в MVC. Нет причин изобретать велосипед.

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

Возможно, вы захотите ознакомиться с Конфигурация проверки подлинности с помощью форм и дополнительные темы . В этой статье рассматривается хранение дополнительных данных (UserId) в билете аутентификации и создание собственного принципала. Оба метода, вероятно, будут соответствовать вашим требованиям.

...