不知不觉. Net Core 已经推出到 3.1 了, 大多数以. Net 为技术栈的公司也开始逐步的切换到了 Core, 从业也快 3 年多了, 一直坚持着. 不管环境怎么变, 坚持自己的当初的选择, 坚持信仰 .Net Core 是个非常优秀的框架, 如果各位是从 webForm 开始, 一步步走到今天, 自然而然就会发现. 微软慢慢的开始将整个框架组件化, 不在像以前那样, 所以的东西都傻瓜化, 比如 WebForm, 拖拖控件往往能搞定大部分的事情. Core 的扩展性很好, 将很多选择权交给我们自己, 而不是强行的让我们去接受他那一套, 对第三方组件的兼容性很好. 换句话说, 很多核心组件微软提供了高层抽象, 如果你想换, 可以, 不想换, 也可以, 用他默认的实现. 其他的优缺点也不一一细说了, 也不是本文的重点. 如果时间允许, 建议大家可以深入的研究. Net Core 的底层.
1, 简介
省去前面的创建 Core Web 项目的一系列操作. VS 帮你自动化初始化好所有的基础组件, 环境. 第一步就是认证. 就是登陆. 当然微软提供了一套登陆组件. 很全, 很完善. 项目在 Core 源码
Security 文件夹下, 源码自行去 GitHub 下载. 里面提供了若干个认证方法, 常见的 Cookie 认证, JwtBear 认证等等. 还包括 Facebook,Google 等远程认证方式.
本文暂时不讲解具体的认证方式, 主要阐述核心认证流程.
(1), 认证系统的执行过程
Core 启动认证系统的方式很简单
很简单的一段代码, 看看它干了什么
很简单, 注入认证中间件, 关于中间件这里就不说多, 不是文本的重点, 自行百度. 看看中间价干了什么.
核心代码, 首先拿到 DI 中注入的处理认证请求处理器集合, 接着去 DI 中获取认证处理方案集合中的处理认证请求上下文的方案类. 接着去处理器集合中拿到处理认证请求上下文的方案类对应的认证请求处理器, 接着执行处理器的 HandleRequestAsync 方法, 完成认证请求上下文的处理. 这意味着我们的认证请求参数是可以被我们做特殊处理的.
接着
处理完认证请求参数之后, 接着去认证方案中拿到默认的认证方案, 不为空, 执行上下文的扩展方法 context.AuthenticateAsync, 这个方法干了什么如下:
执行 DI 中注入的认证服务方法, 并传入上下文和默认的认证方案名称.
先判断存不存在默认认证方案, 不存在抛异常, 接着去所有的认证处理器集合中拿到默认认证方案的处理器. 接着调用处理的认证方法, 认证成功, 判断当前用户身份集合中在临时缓存中存不存在, 不存在, 可以执行 Claim 的转换. 这很好, 说明用户认证成功之后的 Cliam 也是可以被转换的.
只要注入 IClaimsTransformation 服务即可, 你就可以执行你需要的业务的 Claim 转换, 最后返回结果
到这里整个认证流程结束. 非常的简单. 且关键点的扩展微软都预留了. 可以自定义实现
(2), 流转服务的介绍.
上面介绍了整个认证组件的流转过程, 因为我对流程很清楚, 所以大家可能还是不理解. 所以接下去开始介绍流转必须服务的注入.
认证处理器的 Provider 类, 那么 Core 实在哪里注入认证处理器的呢?
这里, 核心也是红框里的, 下面的只是一些依赖组件.
微软注入默认的认证处理器. 看下获取处理器的实现, 对应中间件.
阅读源码发现, Provider 类并不具体实现提供认证处理器的方法. 而是通过 SchemeProvider 来提供.
原来是 IAuthenticationSchemeProvider 类提供认证处理器. 而且是通过反射实现 (这点开销, 就没必要考虑性能问题, 当然你可以考虑重构), 那么问题来了, 在哪里出入 IAuthenticationSchemeProvider 服务内, 回到上面那张图
微软也提供了默认实现, 去看看 GetSchemeAsync 方法的实现
ok, 到这里就说明认证处理器通过向这个字典写入值, 来实现的. 也就是微软认证方案提供了认证处理器.
上面是认证方案的核心字段, HandlerType 就是认证处理器.
AuthenticationSchemeProvider 类维护了一个_schemes 的字典, 通过它向外输出. 认证方案集合提供类.
接着认证处理器集合提供类 AuthenticationHandlerProvider 通过解析
认证方案集合提供类, 拿到所有的认证处理器.
到这里, 很明显, 所有的认证处理器都是通过向 AuthenticationSchemeProvider 的_schemes 字典注入认证处理器. 既然如此, 入口在哪? 在 AuthenticationBuilder 类下面.
下面是 Cookie 认证方式注入认证处理器的方式
AddScmeme 方法. 在配置参数的同时, 指定了处理器.
接着, 回到中间件的图
我们通过 AuthenticationBuilder 的 AddScheme 方法向_schemes 集合写入了认证处理器且配置了处理器的参数, 接着通过 AuthenticationHandlerProvider 拿到了所有的认证处理器.
接着我们通过 Schemes 方案集合拿到所有处理认证请求上下文的处理器, 执行处理认证请求上下文参数. 处理完毕.
接着我们解析 Schemes 中提供的默认认证方案, 代码如下:
根据
这个配置参数, 一般在入口注入:
中配置默认方案名称, 拿到默认认证方案. 再将处理过的认证请求上下文和默认方案传给 IAuthenticationService, 这个 Service 也有默认实现, 如下:
AuthenticationService 将处理过的认证请求上下文交给具体的认证请求处理器来处理. 并返回处理结果. 认证请求处理器前面说过了, 通过 AuthenticationBuilder 的 AddScheme 方法来注入.
到这里, 整个组件的流程介绍结束. 纯属个人理解, 能力有限, 有问题, 请指正, 谢谢.
下面开始介绍基于 Cookie 的认证组件.
来源: https://www.cnblogs.com/GreenLeaves/p/12093033.html