从壹开始 [ Ids4实战 ] 之六 ║ 统一角色管理（上）
前言
书接上文，咱们在上周，通过一篇《思考》 性质的文章，和很多小伙伴简单的讨论了下，如何统一同步处理角色的问题，众说纷纭，这个我一会儿会在下文详细说到，而且我最终也定稿方案了。所以今天咱们就大刀阔斧的开始迁移之路，这个 IdentityServer4 项目也是要尽快的完结，因为第六个系列《设计模式》已经开始了，然后还有直播，和录制视频，积压太多会得不偿失，而且好像还有人让我讲我的项目，所以，这两周先把我在线的项目迁移了，WPF的项目就留在录制 IdentityServer4 视频里给大家详细讲解，文字教程到时候看看要不要补充一下。
那既然说到了角色管理，可能有一部分读过我文章的小伙伴，脑海中稍微有点儿类似的印象，数据管理？好像之前说过，没错！在上上一篇文章中，我们说到了《用户数据管理》，主要就是用户数据的增删改查，然后添加种子数据，从我的 Github 上自动生成，除了用户，当时也生成了一点 Role 信息，只不过那里的 Role 信息，是固定的，不能修改，而且也仅仅是作为User 的 Claim 声明来做处理的，并没有涉及到真正的 Role 管理，比如基本的CURD ，但是今天我们就正式的开始对角色信息进行统一处理了 ，废话不多说，直接开始。
在写这篇文章的时候，是半夜，越写越多，最后发现不得已，无奈的在文章标题里加了个（上）字，其实文章太长也不好，也不知道我为啥这么话痨🙃。
零、今天要实现橙色的部分
一、Role 的数据同步方案之回顾
在刚刚的前言中，我们说到了上一篇文章《五 ║ 多项目集成统一认证中心的思考》里，我们讨论了几种同步 Role 的方案，很是精彩，主要是文章下边的评论很精彩，可能看的多了，一不小心会有一种神仙打架的意味，因此这里我简单的做下总结吧，既是对上篇文章的回顾，也是今天这篇文章的引子，为了看着更清楚，我这里用编号来表示我们的思路：
01、我们的 IdentityServer4 项目是一个去中心化的认证服务中心，他提供一个 token 令牌，来实现我们对资源服务器的授权处理；
02、既然要授权，我们就需要对 Token 做一定的处理，这里一般是增加声明 Claim，常见的就是 Role 信息；
03、然后我们从服务中心成功登录后返回，并携带一个含有 Role Claim信息的 Token 令牌；
04、接着在返回到的资源服务器里，对 api 进行自定义授权，来对当前 Token 令牌，也等同于 Token 的持有者进行访问限制；
05、那这个时候问题来了，我们的资源服务器看起来，本应该是不用关心我们的用户信息和角色信息的，是要交给认证中心的；
06、但是 Blog.Core 项目，我们用到了数据库的动态分配授权，是根据 Role 来分配特定的 api/url 的；
07、也就意味着我们要把 Role 放到资源服务器，但是上边第 05 点，我们明确 Role 的管理是在 Identity 项目的；
08、这个时候方案就来了，
09、一：我们可以做一个定时器，定时将 Identity 认证项目的Role同步到资源服务器；
10、二：在 Identity 项目开发一个 api 接口，方便我们在 资源服务器 里调用；
11、三：直接把 Identity 和 core 项目共用一个 db 数据库，使用一个 Role 表，就完美解决这个问题了；
12、四：单独抽离出一个 Role 做分布式服务管理中心，可以使用 Redis，就是把 Role 单独一个微服务，让所有项目使用；
13、五：最简单的方法，Identity 项目单独一个 db 库，但是我们的资源服务器手动在 controller 上配置Authorize；
14、等等等等，还有其他的一些思路，不列举。
从上边的这一系列大家可以看得出来，我们平时开发还是需要很多的思考的，也是需要多多的讨论，这样才能进步。
最终思考了很久，我还是采用了方案三和方案五，这两个简单的方案，你可能好奇，为啥是两个呢？而且感觉两个背道而驰，一个是合并，一个是分库，怎么能同时使用呢，其实很简单的，因为我有多个资源服务器，这里目前就用两个吧 —— Blog.Core 的前后端分离的 api 项目 和 ChristDDD 的 MVC 项目，当然以后还会有 WPF 项目。
我在 Blog.Core 项目采用方案三，合并到一个数据库，可以很好的解决动态授权问题，
然后在 MVC 项目里，就采用手动在 controller 添加特性的形式吧，也就是方案五，这样就完全满足了需求，
也能够同时给大家展示两种方案，从而达到学习的目的。
好啦，到了现在，大家应该也明白了我以后的设计思路和开发方案了，现在就开始动手处理 Role 数据了。
二、两种管理 ROLE 的方案
说明：以下内容可能有点儿绕，或者有点儿不容易懂，大家不要慌，我会这两篇详细讲解，而且也会在视频中，详细给大家说明的，但是还是尽量能跟的上。
如果你使用 Ids4 项目的话（这里准确来讲，是开发 Identity 的话，因为两者是不一样的哟），会有两种开发方式.
1、简述 Ids4 数据库框架三模块
在我们的 Ids4 项目中，我们在之前的文章中也说到了，一共有三个模块，对应了三个上下文，分别是配置数据ConfigurationDbContext、操作数据PersistedGrantDbContext，然后最后才是我们应用数据(主要是用户角色数据)ApplicationDbContext ，前两个是 IdentityServer4 的相关类库，第三个其实不是 Ids4 官方的，而且 NetCore 自带的一个类库，只是帮助我们更好的处理用户数据的。
我们使用前两个上下文来实现 Ids4 的去中心化认证，而第三个 ApplicationDbContext 只是来存储我们的用户和角色数据的。
因此！这个时候我们知道了，其实我们无论怎么处理用户和角色数据，是不会影响 Ids4 整体性操作的，这个时候我们就恍然大悟了，这个时候两种方案就出来了：
2、自定义封装，实现用户角色数据的持久化
这个第一种就是自己封装一个 Repository 仓储的方式，然后搭配 EFCore 持久化，还可以写多个上下文等等。这种就是我们自定义的开发，这种好处很明显，就是可以很好的进行扩展和自定义处理，而且匹配多个上下文，还可以支持事务等等，如果自己能力较高，或者说，身边正好有这么一个项目案例，可以对比着学习学习，搭建搭建，今天我就不详细的说这个了，下次给大家详细说明，大家这个时候应该懂了，我们开发 Ids4 的思路，无非就是一个持久化的过程，之所以使用 Ids4 这个框架，仅仅是使用了 Ids4 封装了很丰富的、去中心化的 Token 生成机制而已。
我这里简单举个例子，可以这么配置，看个思路就行了，代码是不完整的，我以后会详细说明，这里仅仅是展示一下：
// 配置上下文 public class MyDbContext : DbContext, IConfigurationDbContext { private readonly ConfigurationStoreOptions storeOptions; public MyDbContext(DbContextOptions<MyDbContext> options) : base(options) { }public DbSet<User> User { get; set; } public DbSet<Role> Roles { get; set; } public DbSet<ApiResource> ApiResources { get; set; } protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.ConfigureClientContext(storeOptions); modelBuilder.ConfigureResourcesContext(storeOptions); base.OnModelCreating(modelBuilder); } } // 正常的注入服务 services.AddDbContext<MyDbContext>(builder => builder.UseOracle(connectionString, options => { options.MigrationsAssembly(migrationsAssembly); options.MigrationsHistoryTable("xxxx"); }));
上边的实体类可以自定义处理，然后我们再写一个仓储，或者是一个类，来处理数据：
public class UserRepository { private readonly MyDbContext _dbContext; public UserRepository(MyDbContext dbContext) { _dbContext = dbContext; } /// <summary> /// 根据SubjectID查询用户信息 /// </summary> /// <param name="subjectId">用户id</param> /// <returns></returns> public IdentityUser FindBySubjectId(string subjectId) { return _dbContext.Set<User>().Where(r => r.SubjectId.Equals(subjectId)).Include(r => r.IdentityUserClaims).SingleOrDefault(); } /// <summary> /// 根据用户名查询用户 /// </summary> /// <param name="username">用户</param> /// <returns></returns> public IdentityUser FindByUsername(string username) { return _dbContext.Set<User>().Where(r => r.Username.Equals(username)).Include(r => r.IdentityUserClaims).SingleOrDefault(); } }
但是如果自己能力不是很高，或者说不想太麻烦的话，可以使用 IdentityServer4 中 Identity 自带的，封装好的一套逻辑来处理，就比如我之前来处理用户数据的时候，用的就是 UserManager 类，我们这时候就使用一个 RoleManager.cs 类。
3、使用NetCore自带 Identity 库
这个其实是很简单的，我们看一下 UserManager 类的命名空间就知道了，这个是微软原生自带的类库，和 Ids4 其实没有太大的关系：
这个类库的名字和 Ids4 也很像，就是叫做 Identity ，一共七个表，来处理用户和角色的关系：
很简单，很方便，也很丰富，那今天我们就先说说这个第二种方案，第一种方案，我们下次再说。
三、利用 Identity 原生结构，处理角色信息
1、自定义 Role 扩展实体类
我们既然要对 Role 进行管理，那我们就需要做下封装，Ids4 默认自带的 IdentityRole 表，仅仅只要三个属性：
public virtual TKey Id {get;set} public virtual string Name{get;set} public virtual string NormalizedName{get;set}
这是肯定不够用的，不仅不够用，我们还需要和资源服务器 Blog.Core 项目打通，所以两个实体类要取并集，就是求最全的属性，那我就自定义了一个应用角色表，用来满足和 Blog.Core 项目的统一：
在项目的 Models 文件夹下，新建 ApplicationRole.cs 类：
// Add profile data for application roles by adding properties to the ApplicationRole class public class ApplicationRole : IdentityRole<int> { public bool IsDeleted { get; set; } public string Description { get; set; } /// <summary> ///排序 /// </summary> public int OrderSort { get; set; } /// <summary> /// 是否激活 /// </summary> public bool Enabled { get; set; } /// <summary> /// 创建ID /// </summary> public int? CreateId { get; set; } /// <summary> /// 创建者 /// </summary> public string CreateBy { get; set; } /// <summary> /// 创建时间 /// </summary> public DateTime? CreateTime { get; set; } = DateTime.Now; /// <summary> /// 修改ID /// </summary> public int? ModifyId { get; set; } /// <summary> /// 修改者 /// </summary> public string ModifyBy { get; set; } /// <summary> /// 修改时间 /// </summary> public DateTime? ModifyTime { get; set; } = DateTime.Now;
// 同理我们需要创建一个 ApplicationUserRole 关系表，具体的看我源码吧 public ICollection<ApplicationUserRole> UserRoles { get; set; }
这里可以做任何的自定义，只不过这里有一个小的问题，那就是这个 Id 的问题，我们的 Blog.Core 项目使用的是 Int 整型自增，那 IdentityServer4 用的是 string 方式，所以说，这里要做下处理，一般有两种办法，一种是把 IdentityServer4 项目的string 全部切换成 int，然后还有一种，就是修改 Blog.Core 资源服务器的主键 Id 为 Guid string .
其实这两种都可以，而且一般人都是采用的 Guid 和 string 的形式，但是很不巧的是，我的 Blog.Core 项目使用的是 Int 类型，所以，这里我就统一修改成 int，大家根据需要自己处理吧，具体如何处理 int 呢，大家多注意下文的类型就行，我会点明注意的点。
2、修改注入的 Identity 服务
我们需要把我们的 ApplicationRole 信息也注入到服务里去，这里不多说：
services.AddIdentity<ApplicationUser, ApplicationRole>() .AddEntityFrameworkStores<ApplicationDbContext>() .AddDefaultTokenProviders();
3、修改应用上下文
因为我们自定义了 ApplicationRole ，所以在数据库上下文中，也需要对 Role 信息单独做处理，而且还比较麻烦，这个具体的，可以通过 F12 查看源码就能了解到相应的逻辑，咱们就直接这么修改：
// 注意下 红色的 int类型，到时候创建的表的主键是 int 类型的。
public class ApplicationDbContext : IdentityDbContext<ApplicationUser, ApplicationRole, int, IdentityUserClaim<int>, ApplicationUserRole, IdentityUserLogin<int>, IdentityRoleClaim<int>, IdentityUserToken<int>> { public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { } protected override void OnModelCreating(ModelBuilder builder) { base.OnModelCreating(builder); builder.Entity<ApplicationUserRole>(userRole => { userRole.HasKey(ur => new { ur.UserId, ur.RoleId }); userRole.HasOne(ur => ur.Role) .WithMany(r => r.UserRoles) .HasForeignKey(ur => ur.RoleId) .IsRequired(); userRole.HasOne(ur => ur.User) .WithMany(r => r.UserRoles) .HasForeignKey(ur => ur.UserId) .IsRequired(); }); builder.Entity<ApplicationRole>() .ToTable("Role"); }
4、数据库迁移，生成 DB
打开我们的控制台：工具 -》Nuget 包管理器 -》程序包管理器控制台，
1、add-migration UpdateRole -Context ApplicationDbContext
2、update-database -Context ApplicationDbContext
这里来一个动图：
然后我们可以看看生成的数据库表结构，可以看到，和之前的表结构，几乎是一样的，可以看到我们右侧的 Identity 生成的表结构，不仅主键变成了一样的 Int 类型，相关的属性字段也都有，如果你有强迫症的话，也可以把字段的长度设为一致，还记得在哪里修改把，就是上下文里，这里不多说：
这里有一个要注意一下，如果我们什么都不操作，默认生成的数据库表名是 AspNetRoles ，我们也可以自定义修改成自己的表名，直接修改实体类名是不行的，因为我们可以看一下生成的迁移记录，无论修改成什么，只要我们的扩展实体类是继承了类IdentityRole，那表名还是默认的 AspNetRoles：
那我们可以通过配置EFCore 的实体映射来做相应的处理，还记得我们刚刚的上下文么，就是这里：
然后我们做一下数据库迁移，最后我们可以看到数据库表名已经变了，具体的可以查看上边的迁移对比图。
完成！是不是这么写已经完成了呢，不是的，现在只是完成了一半，剩下的一半，就是在控制器里，去进行业务逻辑设计了。
5、设计角色的 CURD 页面与业务逻辑
先构造函数注入下我们的 RoleManager 服务，这是 IdentityServer4 已经给我们封装好的类：
然后设计接口，主要就是增删改查，很简单，当然，你也可以像用户管理那样，带上权限信息：
[HttpGet] [Route("account/Roleregister")] public IActionResult RoleRegister(string returnUrl = null) { ViewData["ReturnUrl"] = returnUrl; return View(); } [HttpPost] [Route("account/Roleregister")] [ValidateAntiForgeryToken] public async Task<IActionResult> RoleRegister(RoleRegisterViewModel model, string returnUrl = null) { ViewData["ReturnUrl"] = returnUrl; IdentityResult result = new IdentityResult(); if (ModelState.IsValid) { var roleItem = _roleManager.FindByNameAsync(model.RoleName).Result; if (roleItem == null) { var role = new ApplicationRole { Name = model.RoleName }; result = await _roleManager.CreateAsync(role); if (result.Succeeded) { if (result.Succeeded) { return RedirectToLocal(returnUrl); } } } else { ModelState.AddModelError(string.Empty, $"{roleItem?.Name} already exists"); } AddErrors(result); } // If we got this far, something failed, redisplay form return View(model); } [HttpGet] [Route("account/Roles")] [Authorize] public IActionResult Roles(string returnUrl = null) { ViewData["ReturnUrl"] = returnUrl; var roles = _roleManager.Roles.Where(d => !d.IsDeleted).ToList(); return View(roles); } [HttpGet("{id}")] [Route("account/Roleedit/{id}")] [Authorize(Roles = "SuperAdmin")] public async Task<IActionResult> RoleEdit(string id, string returnUrl = null) { ViewData["ReturnUrl"] = returnUrl; if (id == null) { return NotFound(); } var user = await _roleManager.FindByIdAsync(id); if (user == null) { return NotFound(); } return View(new RoleEditViewModel(user.Id, user.Name)); } [HttpPost] [Route("account/Roleedit/{id}")] [ValidateAntiForgeryToken] [Authorize(Roles = "SuperAdmin")] public async Task<IActionResult> RoleEdit(RoleEditViewModel model, string id, string returnUrl = null) { ViewData["ReturnUrl"] = returnUrl; IdentityResult result = new IdentityResult(); if (ModelState.IsValid) { var roleItem = _roleManager.FindByIdAsync(model.Id).Result; if (roleItem != null) { roleItem.Name = model.RoleName; result = await _roleManager.UpdateAsync(roleItem); if (result.Succeeded) { return RedirectToLocal(returnUrl); } } else { ModelState.AddModelError(string.Empty, $"{roleItem?.Name} no exist!"); } AddErrors(result); } // If we got this far, something failed, redisplay form return View(model); } [HttpPost] [Route("account/Roledelete/{id}")] [Authorize(Roles = "SuperAdmin")] public async Task<JsonResult> RoleDelete(string id) { IdentityResult result = new IdentityResult(); if (ModelState.IsValid) { var roleItem = _roleManager.FindByIdAsync(id).Result; if (roleItem != null) { roleItem.IsDeleted = true； result = await _roleManager.UpdateAsync(roleItem); if (result.Succeeded) { return Json(result); } } else { ModelState.AddModelError(string.Empty, $"{roleItem?.Name} no exist!"); } AddErrors(result); } return Json(result.Errors); }
那剩下的就是我们修改用户的角色信息了，毕竟我们要给用户进行加权限，也就是赋角色操作的嘛。但是😴😴😴
时间很晚了，已经快凌晨了，篇幅太长了，今天就暂时先到这里了，总结来说，今天主要是把角色的相关操作给完整的走了一遍，还是很不错的，很有收获的，以后更精彩，下次再见。
四、Github && Gitee
https://github.com/anjoy8/Blog.IdentityServer
优秀文章参考：
