ASP.NET Core Identity 实战(4)授权过程

  • 时间:
  • 浏览:1
  • 来源:大发5分6合_大发5分6合官网

这种除理器的工作十分简单什么都有我验证当前用户与非 在任意一一俩个多由RoleRequirement指定的角色中。在这里context.Succeed(requirement);指示授权成功,而授权失败一般不时要调用 context.Fail();原因分析分析对于这种需求还原因分析分析有其它除理器进行除理,而此例中调用 context.Fail();能没法确保授权失败,原因分析分析RoleRequirement的除理器只一一俩个多多,什么都有原来做是没法问题报告 报告 的。

在旧的Asp.Net时代,亲们知道MvcFilter这种东西,现在它仍然在,原因分析分析你不了解它,我建议你稍作了解,建议参考官方文档

在已经 的文章里,亲们有提到认证和授权是一一俩个多分开的过程,已经 认证过程不属于Identity。同样授权过程什么都有我属于Identity,授权过程插进Identity系列中将的原因分析分析和认证过程一样——和成员系统插进一块儿容易理解。

这篇文章亲们将一块儿来学习 Asp.Net Core 中的(注:原来描述不准确,稍后会我明白)授权过程

这后边和亲们在项目中写的代码有关什么都有我IAuthorizeHandler的实例,在本文中,亲们写了一一俩个多RoleHandler

不过这种法子,不推荐,原因分析分析原来一句话亲们就将“角色”和“Uri”的绑定“硬编码在代码里了”,在什么都有场景这显然不至少,什么都有接下来亲们要介绍的基于策略的授权就允许亲们自定义授权逻辑,原来就灵活多了

打开已经 创建的项目,再加一一俩个多名为Demo的控制器,控制器代码如下:

在上一篇博客ASP.NET Core Identity 实战(3)认证过程中提到,在Authentication后边件中能没法放置多个Handler,而一一俩个多多是默认激活的,没法剩下的是被动调用的,现在亲们的情况汇报什么都有我由亲们在Authorize底部形态中去选折 一一俩个多Handler来执行,相似亲们在Authentication后边件放在置一一俩个多Handler——CookieAuthenticationHandler和JwtAuthenticationHandler,并经CookieAuthenticationHandler指定为默认,没法亲们想经由Jwt认证时为何办?

现在,一一俩个多最基本的基于策略的授权就完成了。

在弄清的是授权过程在哪里居于的已经 ,亲们先来动手写一写授权的代码,原因分析分析了解策略授权,没法要我快速浏览过这部分

这后边值得再次深入探讨的是 context.AuthenticateAsync(scheme),这是在 HttpAbstractions项目中的扩展法子,它的实现是:

已经 退出登录,再次访问/api/demo,没法原因分析分析跳转到登陆页面,在这种过程中Authorize底部形态起到了至关重要的作用,接下来再加Authorize底部形态,重复上一一俩个多操作,未登录的结果将是:

已经 亲们来实现RoleRequirement对应的除理守护程序运行运行:

另外,原因分析分析亲们什么都有我简单的为 Action法子打上[Authorize]标记,没法它的默认行为什么都有我验证IsAuthenticated与非 true,也什么都有我在认证环节(Authentication 后边件)与非 通过了认证

很显然,后会Authorize底部形态拦截了请求,底部形态什么都有我标记了这种法子时要被授权可不还能能访问,而真正拦截了请求的是——“Mvc 后边件”。Action是由Mvc执行的,Mvc执行后会确认Action上的Authorize底部形态,来选折 与非 要进行授权操作(成功授权能没法访问,失败了会被阻止(比如跳转到登陆)),以及怎样授权(动物园例子中,第八个门卫根据切实的情况汇报决定),也什么都有我自定义授权(角色等等)。

用已经 注册的账户登录系统,

访问/api/demo,你将得到如下结果:

那这是为何做到的呢?

再已经 ,亲们要将已经 写好的RoleHandler注册进Di

还记的HttpContext中一一俩个多多扩展法子叫AuthenticateAsync,作为HttpContext的扩展法子也就原因分析分析,亲们能没法在任何已经 调用它进行认证操作。

原因分析分析指定了scheme,没法重新认证,原因分析分析没法,则使用已经 Authentication后边件的授权结果:

亲们为该策略指定了一一俩个多名字role-policy,已经 指定了这种策略的需求条件,需求条件主什么都有我为了设置策略的初始值,亲们能没法在策略注册时更改需求条件从而灵活控制授权。

亲们假设亲们的授权规则是要求和后边代码片段实现相同效果,即用户具有角色“admin”原因分析分析角色“super-admin”,亲们来逐步实现这种目标:

在企业应用中最为常见的什么都有我基于角色的授权,实现角色授权的法子一种生活生活,一种生活是直接写在Authorize底部形态上:

通过这种个多小例子,亲们很容易就能推断出Authorize底部形态拦截了没法登陆的用户,等等,是Authorize底部形态拦截了请求吗?

最后一步,更换原来的Attribute:

原因分析分析RoleHandler从不清楚要求用户哪些角色,RoleHandler只知道怎样去验证用户含哪些角色,而具体要求用户含哪些角色,是由 RoleRequirement 来决定的,这符合关注点分离和单一职责这种个多编程概念。

指定AuthenticationScheme的代码相似原来:

看它的第八个重载,它是指定了 AuthenticationScheme的名字的,什么都有在Mvc后边件探查到Attribute指定了AuthenticationScheme时,就会重新选折 指定的AuthenticationHandler再次对请求进行认证

IAuthenticationService亲们在 Authentication后边件中也见过,Authentication后边件也是使用了IAuthenticationService,已经 的文章有提到过,这也再次证明了单一原则职责,身份认证后边件负责在管道中认证,而认证一种生活从也有和身份认证后边件捆绑的,上一篇博客ASP.NET Core Identity 实战(3)认证过程的最后有认证的源代码

接下来亲们来编写 RoleRequirement

正如这种节的标题,授权居于在Microsoft.AspNetCore.Mvc.Authorization.AuthorizationFilter中,授权的逻辑相似原来:

授权总共分三步

这部分代码还是很简单的:

到此,授权过程就现在开始了,另外一些什么都有我边边角角的知识点,比如授权已经 怎样操作,哪些很难,就不再文中赘述了

本文中的示例较为简单,也并没法使用完整性的授权底部形态,更完整性的使用法子参考资料什么都有,本文也就太少做介绍。

另外要我参考ASP.NET Core中基于策略的授权来学习更过关于策略授权的内容

这里一一俩个多多重要问题报告 报告 什么都有我:当HttpContext流过Authentication后边件后才到Mvc后边件,而Mvc在确认Action指定的AuthenticationHandler时,Authentication过程原因分析分析现在开始了

要注意的是已经 提到的,亲们原因分析分析将角色授权的逻辑(稍后介绍的Handler)和具体授权的数据分开了。

现在,亲们知道了一一俩个多点

原来们的 RoleRequirement 主要实现的功能什么都有我选折 要含有 的角色,原因分析分析要含有 的角色是在构造函数中选折 的,没法亲们就将角色授权的逻辑(稍后介绍的Handler)和具体授权的数据分开了。