ASP.NET Core - 基于IHttpContextAccessor实现系统级别身份标识

问题引入：

　　我们知道当请求通过认证模块时，会给当前的HttpContext赋予当前用户身份标识，我们在需要授权的控制器中打上[Authorize]授权标签，就可以在ControllerBase的User属性获取到基于声明的权限标识(ClaimsPrincipal)。遗憾的是这只是针对Controller层面，很多场景下我们是需要在Service层乃至数据层获直接使用用户信息，这种情况我们就使用不了User了。　　

解决方案：

　　在Asp.net 4.x时代，我们通常的做法是通过HttpContext.Current获取当前请求的上下文进而获取到当前的User属性，所以问题的切入点在于我们如何获取当前的HttpContext上下文，Aspnet Core是通过注入HttpContext的访问器对象IHttpContextAccessor来获取当前的HttpContext。

　　首先我们需要在Startup的ConfigureServices方法中注册IHttpContextAccessor的实例

　　有了这个注册，我们封装一个方法从IHttpContextAccessor 的HttpContext中获取对应的ClaimsPrincipal，如下（这里面的原理在后面的认证授权文章将会讲解到，大概的原理是认证通过后，User是具有当前用户的身份标志的ClaimsPrincipal）：

640?wx_fmt=png

　　在Startup的ConfigureServices方法中，我们一样把这个类也加入注册中

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
    services.AddSingleton<IPrincipalAccessor, PrincipalAccessor>();
    ....
}

　　有了以上这些基础架构提供的东西，剩下的是我们该需要如何从ClaimsPrincipal获取到对应的Claims了，在这里我们定义一个ClaimsAccessor类负责从PrincipalAccessor把用户的身份标志信息提取出来，比如用户的角色，Id等业务数据，这些是需要在获取Token时系统所提供过的信息。

640?wx_fmt=png

　　同样我们在Startup的ConfigureServices方法中把IClaimsAccessor注册进来

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
    services.AddSingleton<IPrincipalAccessor, PrincipalAccessor>();
    services.AddSingleton<IClaimsAccessor, ClaimsAccessor>();
    ....
}

　　这样我们所涉及到的需获取身份标志的基础类都已经定义好，来看看我们该如何使用这些基础类。

　　使用

　　在有了以上的这些类，我们需要的是在业务中通过依赖注入方式来解析出我们所需的对象，来好的让我们看看该如何具体使用　　

640?wx_fmt=png

　　当我们的IClaimsAccessor解析出来时，我们就获取到所有的Claims信息，可以基于这些信息提取访问用户的身份标志，这样我们就不仅仅局限于在Controller层面才能获取用户的身份标志了，至此我们的系统级别的标识已经完成，记得在项目的启动项中利用ASP.NET Core的容器把服务注册进来，在需通的地方解析出来即可使用。

　　改进

　　这时能满足我们的业务吗？能！但是对于我们稍微要求高点的程序员，我们就可以发现，如果每个服务都按照上面的写法的话，明显在实际应用中需要写很多重复的代码，每次都需要手动进行构造注入会比较繁琐，好吧，我们可以利用面向对象的特点，创建基类进行继承进行优雅且可复用的简化和改进

　　首先我们先定义一个ServiceProviderInstance类

　　public class ServiceProviderInstance
    {
        public static IServiceProvider Instance { get; set; }
    }

　　这个类的作用是保存IServiceProvider的一个实例，为什么需要这样呢？这里的一个设计思想是，我们如何能顺利解析出我们所需的IClaimsAccessor对象进而得到我们所需的信息？在ASP.NET Core的容器中，系统提供了IServiceCollection来注册服务和提供了IServiceProvider这个让我们解析各种注册过的服务（具体可参考ASP.NET Core - 依赖注入文章所讲解的依赖注入），这时我们的目标就是需要获取到当前应用的IServiceProvider实例，所以这个ServiceProviderInstance类的作用时为了获取IServiceProvider所设计出来的静态类。

　　如何获取到应用的IServiceProvider实例？

　　在应用初始化过程中，WebHostBuilder会利用ServiceCollection来创建新的ServiceProvider来供系统使用，所以我们在Startup类的Configure方法中，通过ApplicationBuilder的ApplicationServices属性就能获取到系统的ServiceProvider实例，在此我们利用ServiceProviderInstance的Instance属性保存当前的IServiceProvider以供系统后面使用　　

　　public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
     {
            ...
            ServiceProviderInstance.Instance = app.ApplicationServices;
    }

　　在获取到了系统的IServiceProvider实例后，剩下的就是利用这个实例把我们前面注册的基础服务IClaimsAccessor解析出来了

640?wx_fmt=png