当前位置:   article > 正文

SpringSecurity5-教程3-oauth2登录源码分析_authorization_request_not_found

authorization_request_not_found

基于用户名密码登录的demo实现oauth2授权码登录!

demo下载

配置解释

http.authorizeRequests()
        .mvcMatchers("/login").permitAll() //放行login请求
        .anyRequest().authenticated()//代表其他请求需要认证
        .and()
        .formLogin()//配置表单认证
        .loginPage("/login")//用来指定自定义登录界面,不使用SpringSecurity默认登录界面  注意:一旦自定义登录页面,必须指定登录url
        .loginProcessingUrl("/doLogin")//指定处理登录的请求url
        .and()
        .oauth2Login() // 开启oauth2登录
        .loginPage("/login") //不使用默认的oauth登录页面,否则无法密码登录
        .successHandler(oauth2AuthenticationSuccessHandler)
        .and()
        .csrf().disable(); //禁止csrf 跨站请求保护

源码分析

1. 访问根路径,重定向到登录页

在FilterChainProxy如下打断点:

浏览器访问:http://localhost:8035/

进入断点,观察过滤器:

可知多了两个Filter:

OAuth2AuthorizationRequestRedirectFilter :重定向过滤器,即当未认证时,重定向到登录页

OAuth2LoginAuthenticationFilter:授权登录过滤器,处理指定的授权登录

而且在UsernamePasswordAuthenticationFilter之前;

debug放行直到进入OAuth2AuthorizationRequestFilter:

因为当前请求根路径。并非授权登录请求,因此继续执行后续Filter;

debug放行进入OAuth2LoginAuthenticationFilter:

首先执行方法requiresAuthentication判断当前请求是否需要当前AuthenticationFilter执行认证:

可知OAuth2AuthenticationFilter处理的请求是/login/oauth2/code/,因此返回false:

不需要当前Filter执行认证,因此继续执行后续Filter:

直到现在,其实新加入的两个Filter都没有起作用,后续流程就是认证为匿名用户,授权校验抛出AccessDeniedExcepiton,然后ExceptionTranslateFilter处理重定向到登录页。

2. 点击gitee登录,页面重定向到gitee授权登录页面

提前打开https://gitee.com/,如果已登录,请先退出登录。

保持FilterChainProxy断点,点击gitee登录,请求 /oauth2/authorization/gitee

进入断点:

debug放行,直到进入OAuth2AuthorizationRequestRedirectFilter :

判断是否是授权登录请求,进入resolve方法:

进入resolveRegistrationId:

pattern是/oauth2/authorization/{registrationId},因此可解析出registrationId是gitee

继续执行getAction方法:

请求中没有action参数,返回默认的:login

debug下一步,进入resolve:

denbug下一步,发起重定向:

首先执行saveAuthorizationRequest方法,即保存本次请求相关的信息,以用于三方平台回调时可以再次获取,例如当回调时需要检查state参数是否一致,以保证安全;

进入sendRedirect方法:

debug放行,后续Filter不被执行,页面渲染授权登录页面(如果浏览器已登录过gitee将不会出现以下页面,而是直接进行回调,因为已登录啦):

3. gitee登录完成后回调完成认证,并响应信息

首次gitee授权登录时还需要确认授权,之后不会再出现该步骤;

保持FilterChainProxy断点,gitee登录和确认授权后,进入该断点:

当前请求是/login/oauth2/code/gitee,就是gitee回调请求,debug放行进入OAuth2LoginAuthenticationFilter:

同样先执行抽象父类AbstractAuthenticationProcessingFilter的判断是否需要执行认证的方法requiresAuthentication:

pattern是/login/oauth2/code/*,当前回调请求的url是/login/oauth2/code/gitee,因此匹配,开始执行认证:

进入OAuth2LoginAuthenticationFilter.attemptAuthentication方法:

可以看到回调请求中包含授权码code和state两个参数;

在removeAuthorizationRequest方法中根据state参数从会话中查询授权登录之前保存的请求对象(请求对象也有state参数),如果找不到则抛出异常:AUTHORIZATION_REQUEST_NOT_FOUND_ERROR_CODE

意思就是这次授权回调和当前会话无关,为了安全,有可能是黑客乱搞的链接被用户误点了,因此这里直接抛出异常;

继续执行:

构造认证请求,然后使用工厂模式执行认证,这个和用户名密码认证是一样的:

进入authenticate方法,并debug放行到下图断点:

可知处理OAuth2LoginAuthenticationToken的provider是OAuth2LoginAuthenticationProvider,进入:

debug放行:

这里会将OAuth2AuthenticationToken保存到SecurityContextHolder中,以使得SecurityContextPersistenceFilter能持久化到会话中,

可发现该认证结果包含了大量gitee用户信息,这和密码登录后认证为本地用户是不同的,本地用户可能有id等信息,gitee的id和本地用户的id不同;因此如果Controller中获取该Authentication对象后还需要做转换以匹配本地用户,这是不方便的,因此可以自定义认证成功后处理器中完成用户匹配:

handler中也使用了工厂模式,以支持不同授权登录方式对应不同的用户匹配方法;

debug放行,Controller返回当前认证信息:

4. 使用SavedRequestAwareAuthenticationSuccessHandler可实现回调原始请求

重启浏览器,访问localhost:8035/test,跳转登录页,使用gitee授权登录后,页面会重定向到localhost:8035/test

但是当前后端分离时,通过默认的SavedRequestAwareAuthenticationSuccessHandler就不能实现重定向到原始请求了。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/羊村懒王/article/detail/84023
推荐阅读
相关标签
  

闽ICP备14008679号