Есть ли какая-либо польза для хранения пользовательской информации в AspNetUserClaims с помощью Asp.Net Identity 2?

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

public class ApplicationUser : IdentityUser {
        public async Task<ClaimsIdentity> GenerateUserIdentityAsync(UserManager<ApplicationUser> manager) {
            // Note the authenticationType must match the one defined in CookieAuthenticationOptions.AuthenticationType
            var userIdentity = await manager.CreateIdentityAsync(this, DefaultAuthenticationTypes.ApplicationCookie);
            // Add custom user claims here
            return userIdentity;
        }
        public string FirstName { get; set; }
        public string LastName { get; set; }

    }

Здесь добавлены FirstName и LastName, и они появятся в виде дополнительных полей в таблице AspNetUsers.

Однако теперь кажется, что теперь с Asp.Net Identity существует также возможность хранить этот тип информации в таблице AspNetUserClaims.

Может кто-нибудь объяснить мне. Идти вперед - это такая информация, которая может быть сохранена в AspNetUserClaims. Если да, то у кого-нибудь есть примеры этого.

Ответ 1

В конце дня ваш подписанный пользователь будет преобразован в ряд претензий, хранящихся в ClaimsIdentity, представляющих вашего пользователя в HttpContext.User.Identity. Вы можете сохранить имя FirstName/LastName в виде столбцов в пользовательской таблице, которые затем можно явно считывать и конвертировать в соответствующие претензии (при желании), или вы можете хранить их непосредственно в качестве претензий в таблице AspnetUserClaims (которая просто хранит их как два строковых столбца), которые по умолчанию будут автоматически добавлены в вашу идентификационную форму пользователя. Оба метода более или менее эквивалентны, хотя, следовательно, его личные предпочтения.

BTW - единственная причина, по которой вы захотите их в пользователе ClaimsIdentity вообще, - это если вы хотите сохранить удаленный db только для отображения имени и всегда используете утверждения FirstName/LastName в ClaimsIdentity. Если вы выбираете пользователя и используете user.FirstName вместо этого, это не так много, чтобы генерировать утверждения имен.

Ответ 2

В дополнение к @Hao Kung, когда претензии будут длиннее, чем разрешенные возможности Cookie браузера, информация о претензиях может быть обрезана.

Согласно статье Thinktecture Identity Server, одной из известных альтернатив по умолчанию AspNet Identity, сказано ниже:

Как только ваше приложение становится сложным, так же как и количество претензий. По умолчанию все претензии сохраняются как часть файла cookie сеанса, а браузеры, такие как Safari, накладывают ограничение на размер файла cookie. Итак, в один прекрасный день, когда вы добавляете еще несколько претензий к приложению, вы начнете получать ошибки сериализации. Это потому, что только частичный cookie будет отправлен обратно на сервер, а сервер не знает, что с ним делать. Таким образом, решение этой проблемы - создать токен безопасности в режиме "Ссылка". Это означает сохранение маркера на сервере и просто сохранение идентификатора ссылочного сеанса в качестве файла cookie. См. Изображение ниже. Размер файла cookie - всего несколько байтов: