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

У меня был тот же вопрос, когда я реализовал пользовательский поставщик членства для 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.

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

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

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

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