使用Asp.Net Identity 2在AspNetUserClaims中存储用户信息有什么好处吗？

Question

我想存储一些额外的用户信息.据我所知,以下是通常的选择:

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中的信息.如果是这样,那么任何人都有这方面的任何例子.

Answer 1

在一天结束时,您的已登录用户将转换为存储在ClaimsIdentity中的一系列声明,这些声明代表您在HttpContext.User.Identity中的用户.您可以选择将FirstName/LastName存储为用户表中的列,然后您可以显式读出并转换为相应的声明(如果需要),或者您可以将它们直接存储为AspnetUserClaims表中的声明(仅存储它们)作为两个字符串列)默认情况下会自动添加到用户的声明标识中.这两种方法或多或少都是等价的,所以它取决于个人喜好.

BTW是你在用户的ClaimsIdentity中想要这些的唯一原因,就是如果你想保存db命中只是为了显示名字,并且总是在ClaimsIdentity中使用FirstName/LastName声明.如果您获取用户,并使用user.FirstName,那么生成名称声明也没有太大价值.

Answer 2

除了@Hao Kung 之外，当声明将超过浏览器允许的 Cookie 容量时，声明信息可以被修剪。

根据Thinktecture Identity Server 文章，这是默认 AspNet Identity 的著名替代品之一，如下所述。

一旦您的申请变得复杂，需要处理的索赔数量也会随之增加。默认情况下，所有声明都作为会话 cookie 的一部分存储，并且 Safari 等浏览器对 cookie 的大小施加了限制。所以有一天，当您向应用程序添加更多声明时，您将开始收到序列化错误。那是因为只有部分 cookie 会被发送回服务器，而服务器不知道如何处理它。所以这个问题的解决方案是在“参考”模式下创建安全令牌。这意味着将令牌存储在服务器上，并将参考会话 ID 存储为 cookie。见下图。cookie 大小只有几个字节：