二级网站建设基本情况,wordpress的标签设置主页,网站的系统建设方式有哪些内容,网页设计和网站制作问题引入#xff1a;我们知道当请求通过认证模块时#xff0c;会给当前的HttpContext赋予当前用户身份标识#xff0c;我们在需要授权的控制器中打上[Authorize]授权标签#xff0c;就可以在ControllerBase的User属性获取到基于声明的权限标识(ClaimsPrincipal)。遗憾的是这… 问题引入 我们知道当请求通过认证模块时会给当前的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 在Startup的ConfigureServices方法中我们一样把这个类也加入注册中public void ConfigureServices(IServiceCollection services){ services.AddSingletonIHttpContextAccessor, HttpContextAccessor(); services.AddSingletonIPrincipalAccessor, PrincipalAccessor(); ....} 有了以上这些基础架构提供的东西剩下的是我们该需要如何从ClaimsPrincipal获取到对应的Claims了在这里我们定义一个ClaimsAccessor类负责从PrincipalAccessor把用户的身份标志信息提取出来比如用户的角色Id等业务数据这些是需要在获取Token时系统所提供过的信息。 同样我们在Startup的ConfigureServices方法中把IClaimsAccessor注册进来public void ConfigureServices(IServiceCollection services){ services.AddSingletonIHttpContextAccessor, HttpContextAccessor(); services.AddSingletonIPrincipalAccessor, PrincipalAccessor(); services.AddSingletonIClaimsAccessor, ClaimsAccessor(); ....} 这样我们所涉及到的需获取身份标志的基础类都已经定义好来看看我们该如何使用这些基础类。 使用 在有了以上的这些类我们需要的是在业务中通过依赖注入方式来解析出我们所需的对象来好的让我们看看该如何具体使用 当我们的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解析出来了 好的让我们看看改进后在一个实际环境中该如何使用 让所有每个子类都继承了ServiceBase这样在所有的业务层都可以直接获取到用户的身份信息而不用写太多的重复代码。 总结 1. 利用ASP.NET Core提供的IHttpContextAccessor来获取HttpContext的User属性 2. 封装一系列的基础类和利用依赖注入来解析出所有的Claims 3. 为了避免过多的侵入式代码优雅且可复用的创建ServiceBase给所有的业务类使用 让我知道如果你有更好的想法或建议原文地址https://www.cnblogs.com/lex-wu/p/10528109.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
