ASP.NET没有魔法——ASP.NET Identity 的“多重”身份验证 (2)

  

ASP.NET没有魔法——ASP.NET Identity 的“多重”身份验证

  根据注释看出它用于与串联到管道的身份验证中间件进行交互,并且提供了身份验证AuthenticateAsync、拒绝Challenge(我将其翻译拒绝或质疑等意思,换句话就是身份验证未通过)、登入SignIn、登出SignOut以及获取验证方式GetAuthenticationTypes等方法。
  对于AuthenticationManager可以这么理解,每一次请求都会创建一个AuthenticationManager,它携带了当前请求的用户信息User,然后管理所有串联到Owin管道的身份验证中间件,通过这一系列的中间件完成了用户的验证与拒绝、登入与登出等功能

  需要注意的是AuthenticateAsync返回的是一个验证结果,该结果中包含除了验证结果外还包含了用户信息,而SignIn方法实际上是将用户信息添加到(或者说替换)当前请求上下文的用户信息,所以大部分情况下AuthenticateAsync和SignIn方法是连续使用的。

AuthenticationMiddleware&AuthenticationHandler

  AuthenticationMiddleware和AuthenticationHandler作为模板代码,对中间件的执行以及处理器的处理方法进行了限制:
  AuthenticationMiddleware的执行方法:

  

ASP.NET没有魔法——ASP.NET Identity 的“多重”身份验证

  分为四个阶段:1. 处理器的创建。2. 处理器的初始化。3. 处理器的调用。4. 处理器的销毁。

  对于AuthenticationHandler来说,它有几个重要的过程:
  1. 初始化:将当前处理器注册到AuthenticationManager中,另外如果当前中间件的模式为积极模式,那么调用身份验证方法,否则身份验证方法就只能通过AuthenticationManager调用。(注:InitializeCoreAsync的具体实现在子类中)

  

ASP.NET没有魔法——ASP.NET Identity 的“多重”身份验证

  2. 执行:

  从上面的分析可以知道,在身份验证处理其中有一个专门用于身份验证的方法AuthenticateAsync,那么执行方法是做什么用的呢?在基于Identity的ASP.NET应用程序中身份验证方法只有在积极模式下时才会对自动对请求进行身份验证,并且无论是否通过验证都不会对请求进行任何的处理(即使没有通过身份验证仍旧能够将请求送到Controller、Action的执行,因为它们是可以被匿名调用的),而有一种情况就是当服务器处理请求时就能够确定该请求应该如何处理,如通过第三方账户登录后会在Url的查询字符串上携带一些Token等信息,那么这个时候能够确定的就是需要根据这些信息进行处理进而完成身份验证而不是还可以将请求交给Controler处理,在这种情况下就可以将这些处理的逻辑放到Invoke方法中,Invoke方法如果返回true时,管道将不再继续往下执行(见中间件的Invoke方法)。微软、Google等社交账户验证时,它的验证逻辑是写在这个InvokeAsync方法中的,而Cookie验证的中间件就默认返回false将请求交与后续组件处理,后续详细介绍Owin的第三方验证。

  

ASP.NET没有魔法——ASP.NET Identity 的“多重”身份验证

   3. 销毁:当请求处于返回阶段时,会触发身份验证处理器的销毁过程,整个过程包括将身份信息写入响应信息中(如Cookie验证会将AuthenticationTicket对象序列化加密后写到Cookie中),并执行子类的一些销毁逻辑,最后将添加到AuthenticationManager中的处理器删除。

  

ASP.NET没有魔法——ASP.NET Identity 的“多重”身份验证

SignInManager&AuthenticationManagerExtensions

  SignInManager用于管理用户的登录逻辑,如登录、使用密码登录、双因子登录、外部登录等等,它是对UserManager与AuthenticationManager的封装

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpzsyf.html