ASP.NET Core Identity + Mysql（实战一）——注册登陆

登陆和注册效果图

在进行实战之前，我们先来了解一下Identity。

ASP.NET Core Identity是用于构建ASP.NET Core Web应用程序的成员资格系统，包括成员资格、登录和用户数据存储。简单的来讲包括：

1.用户数据存储（使用任意你喜欢的关系型数据库，从sqllite到mysql、sqlserver等等，由Entity Framwork 支持）
2.登陆、注册外加身份认证（基于cookie的身份认证，如果你使用Vs那么还可以生成用于注册登录的用户界面及处理代码）
3.角色管理
4.基于声明的认证模式Claims Based Authentication

先来看看生成的数据表

_EFMigrationsHistory 是 Ef的迁移历史表不必关注此表

AspNetUserClaims、AspNetRoleClaims是用户和角色的声明表，之前我们提到 Identity 是基于声明的认证模式（Claims Based Authentication）的，Claim在其中扮演者很重要的角色，甚至角色（Role）都被转换成了Claim，Claim相关会在后面专门讲解，如果你不了解它，不要着急

AspNetUsers、AspNetRoles和AspNetUserRoles存储用户和角色信息

AspNetUserTokens、AspNetUserLogins存储的是用户使用的外部登陆提供商的信息和Token，外部登陆提供商指的是像微博、QQ、微信、Google、微软这类提供oauth 或者 openid connect 登陆的厂商。比如 segmentfault 就可以使用微博登陆

接下来就要解释下最为重要的一张表AspNetUsers

列名	说明
Id	主键 默认是 nvarchar(450) 但事实上是存储的Guid字符串，它是完全随机的无序Guid，那么它可能带来的隐患就是当用户量非常大的时候，创建用户可能变慢
AccessFailedCount	这个是用来记录用户尝试登陆却登陆失败的次数，我们可以通过这个来确定在什么时候需要锁定用户
ConcurrencyStamp	同步标记，每当用户记录被更改时必须要更改此列的值，事实上存储的是Guid，并且在创建用户模型的时候直接在属性上初始化随机值
Email和NormalizedEmail	Email就是Email，NormalizedEmail是 规范化后的Email。NormalizedEmail 只是将email 的值变成大写了，这样会提高数据库的查询效率（NormalizedEmail在使用时你可以不用关心，你也不要去手动更改它的值，因为当用户创建或者用户资料更新的时候 NormalizedEmail都会被自动更新）
UserName 和NormalizedUserName	UserName就是UserName NormalizedUserName 还是规范化之后的UserName，也就是转换到大写。它们的行为和上述的 Email、NormalizedEmail 一致，就不赘述了
EmailConfirmed	邮件已经确认，这是个bit（bool）类型的列，前文提到Identity含有发送和验证确认邮件的功能，在创建用户的时候这个值默认是false ，确认链接由 Identity生成，之后交由 IEmailSender发送。
LockoutEnabled、LockoutEnd	他们的数据类型是 bit和datetimeoffset(7)，LockoutEnabled指示这个用户可不可以被锁定，LockoutEnd指定锁定的到期日期，null 或者一个过去的时间，代表这个用户没有被锁定
PasswordHash	密码哈希，Identity使用的hash 强度是比较高的，暴力破解的难度十分大
SecurityStamp	安全标记,一个随机值，在用户凭据相关的内容更改时，必须更改此项的值，事实存储的是Guid
PhoneNumber、PhoneNumberConfirmed	电话和电话已确认，比较容易理解
TwoFactorEnabled	指示当前用户是否开启了双因子验证