-
【security】spring security放行不生效,security放行后还是被拦截，路径变成了error
文章目录
之前写了篇关于security认证的文章 感觉对security了解多了一点，直到遇到过滤器层面的问题，才明白security终究还是那个复杂的security。
security最初的配置
@Configuration public class SecuritySecureConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { // 登录成功处理类 SavedRequestAwareAuthenticationSuccessHandler successHandler = new SavedRequestAwareAuthenticationSuccessHandler(); successHandler.setTargetUrlParameter("redirectTo"); http.authorizeRequests() //静态文件允许访问 .antMatchers().permitAll() // 放行 .antMatchers( "/assets/**","/login","/test/**","/testfather/**","/testes/**","/advice/**","css/**","/js/**","/image/*").permitAll() //其他所有请求需要登录, anyRequest 不能配置在 antMatchers 前面 .anyRequest().authenticated() .and() //登录页面配置，用于替换security默认页面 .formLogin().loginPage( "/login").successHandler(successHandler).and() //登出页面配置，用于替换security默认页面 .logout().logoutUrl( "/logout").and() .httpBasic().and() .csrf() .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()) .ignoringAntMatchers( "/instances", "/actuator/**" ); } }- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
情况描述： test对应的controller get请求的接口可以访问，但是put,delete 等其它请求无法访问
这个无法访问表现形式和日志级别有关，如果日志级别开的是error 那表现形式就是接口打断点无法进入，控制台无任何报错, postman接口返回的是401
如果日志级别开的是debug 那么会报错 access is define初步改进后的配置
在该类中新增一个方法 发现新增后 除了get请求 其它请求也能访问了 问题解决。
后面经过查询得知WebSecurity 和 HttpSecurity 的区别： WebSecurity不走过滤链 通俗的说
不经过各种复杂的filter 直接就放行了 而HttpSecurity 是会经过各种filter的。
在我之前的security认证的那篇博客中有举例 /login 就是典型的走过滤链的接口/** * configure(WebSecurity web)不走过滤链的放行 * 即不通过security 完全对外的/最大级别的放行 **/ @Override public void configure(WebSecurity web) throws Exception { // 直接放行了 如果是login接口 必须通过HttpSecurity 走过滤链 因为登录涉及 SecurityContextHolder web.ignoring().antMatchers("/test/**","/testfather/**","/testes/**"); }- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
排查真实原因
经过上面的操作后 问题是解决了 而且其实有些我们自己写的接口（如/test/**） 确实可以不需要经过过滤链，但是疑惑还在 .antMatchers( " ”).permitAll(） 印象中都是这么放行的，那为什么就出现了get被放行 ， put，delete等方法被拦截呢？
下面复盘排查步骤：
-
开始分析与调试： 被拦截说明放行失败，说明antMatchers方法路径匹配可能出现问题,那我们先跟进去看 最终跟到的方法是
AntPathRequestMatcher 类中的public boolean matches(HttpServletRequest request) 方法public boolean matches(HttpServletRequest request) {
//默认会调用antMatchers（null,"/test/**/）就是说我们没有传httpMethod
// httpMethod 为null 不走该判断
if (this.httpMethod != null && StringUtils.hasText(request.getMethod()) && this.httpMethod != valueOf(request.getMethod())) {
if (logger.isDebugEnabled()) {
logger.debug(“Request '” + request.getMethod() + " " + this.getRequestPath(request) + “’ doesn’t match '” + this.httpMethod + " " + this.pattern + “'”);
}return false; // 如果antMatchers（/**）全部放行 // 也不走该判断 } else if (this.pattern.equals("/**")) { if (logger.isDebugEnabled()) { logger.debug("Request '" + this.getRequestPath(request) + "' matched by universal pattern '/**'"); } return true; } else { // 核心就是这儿了 获取url 用于比较 String url = this.getRequestPath(request); if (logger.isDebugEnabled()) { logger.debug("Checking match of request : '" + url + "'; against '" + this.pattern + "'"); } // 去比较url和antMatchers里面的pattern return this.matcher.matches(url); } }- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
按理来说我们发起的请求是什么 那url就是什么 当debug的时候 意外的发现了是/error 当路径没找到的时候 会重定向到/error 那第一阶段的原因是明白了 路径变成了/error 所以匹配不上 没有放行。
-
继续观察debug级别的日志
所以不得不说 debug级别的日志 在很多时候是有作用的 即使在开发中也不应该简单粗暴的调成error
/testes/idx 是我发起请求的url 可以发现
经过Checking match of request : ‘/testes/idx’; against ‘/instances’和’/actuator/**’ 之后 出现了一行
Invalid CSRF token found for , 再接下来 路径就变成了/error ，那么问题就出在这儿了。通过查阅资料后得知 security防御csrf攻击的方法 写在org.springframework.security.web.csrf路径下的CsrfFilter类
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
request.setAttribute(HttpServletResponse.class.getName(), response);
CsrfToken csrfToken = this.tokenRepository.loadToken(request);
boolean missingToken = csrfToken == null;
if (missingToken) {
csrfToken = this.tokenRepository.generateToken(request);
this.tokenRepository.saveToken(csrfToken, request, response);
}request.setAttribute(CsrfToken.class.getName(), csrfToken); request.setAttribute(csrfToken.getParameterName(), csrfToken); /** private DefaultRequiresCsrfMatcher() { this.allowedMethods = new HashSet(Arrays.asList( "GET", "HEAD", "TRACE", "OPTIONS" )); } **/ // 可以看到除了 "GET", "HEAD", "TRACE", "OPTIONS" 四种方式 其它请求都会被拦截 if (!this.requireCsrfProtectionMatcher.matches(request)) { filterChain.doFilter(request, response); } else { // 其它请求 没有token会被拦截 String actualToken = request.getHeader(csrfToken.getHeaderName()); if (actualToken == null) { actualToken = request.getParameter(csrfToken.getParameterName()); } if (!csrfToken.getToken().equals(actualToken)) { if (this.logger.isDebugEnabled()) { // 我们在控制台看到的输出 this.logger.debug("Invalid CSRF token found for " + UrlUtils.buildFullRequestUrl(request)); } if (missingToken) { this.accessDeniedHandler.handle(request, response, new MissingCsrfTokenException(actualToken)); } else { this.accessDeniedHandler.handle(request, response, new InvalidCsrfTokenException(csrfToken, actualToken)); } } else { filterChain.doFilter(request, response); } } }- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
这就是为什么我们get请求可以访问 而put,delete等请求失败的原因。
更加合理的配置
@Configuration public class SecuritySecureConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { // 登录成功处理类 SavedRequestAwareAuthenticationSuccessHandler successHandler = new SavedRequestAwareAuthenticationSuccessHandler(); successHandler.setTargetUrlParameter("redirectTo"); http.authorizeRequests() //静态文件允许访问 .antMatchers().permitAll() // 放行 .antMatchers( "/assets/**","/login","/test/**","/testfather/**","/testes/**","/advice/**","css/**","/js/**","/image/*").permitAll() //其他所有请求需要登录, anyRequest 不能配置在 antMatchers 前面 .anyRequest().authenticated() .and() //登录页面配置，用于替换security默认页面 .formLogin().loginPage( "/login").successHandler(successHandler).and() //登出页面配置，用于替换security默认页面 .logout().logoutUrl( "/logout").and() .httpBasic().and() // 开启了csrf防御 如果要放行/test/** 还需要在下面ignoringAntMatchers进行配置 .csrf() .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()) // 这里还需要放行 当然如果是 .csrf().disable()就不会有这个问题了 .ignoringAntMatchers( "/instances", "/actuator/**", "/test/**", "/advice/**", "/testes/**" ); } }- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
为什么有的项目没有ignoringAntMatchers配置也放行成功了呢？ 因为那些项目 很可能直接.csrf().disable() 所以不会出现该问题
题外话： 想必可能有同学听过 controller层接口必须捕获异常 ，如果不捕获 其中坑点之一就和这个security框架的.csrf()有关：
* 异常没有捕获 ==》 * 如果当开启了 csrf 且又没有放行时 (在 WebSecurity 放行了 否则进不来接口) 异常会抛到 security 导致security报错（同样需要debug级别日志查看 error看不到） 且返回401 * 换句话说：WebSecurity放行的方式 还需配合接口的try catch 否则接口报错了 也会返回401 * 当然 其它情况可能也会因为异常没捕获 而造成未知结果 * 所以我们还是应该遵循规范：接口必须异常捕获- 1
- 2
- 3
- 4
- 5
先自我介绍一下，小编13年上师交大毕业，曾经在小公司待过，去过华为OPPO等大厂，18年进入阿里，直到现在。深知大多数初中级java工程师，想要升技能，往往是需要自己摸索成长或是报班学习，但对于培训机构动则近万元的学费，着实压力不小。自己不成体系的自学效率很低又漫长，而且容易碰到天花板技术停止不前。因此我收集了一份《java开发全套学习资料》送给大家，初衷也很简单，就是希望帮助到想自学又不知道该从何学起的朋友，同时减轻大家的负担。添加下方名片，即可获取全套学习资料哦
-
相关阅读:
SpringBoot+Mybaits搭建通用管理系统实例五：登录健权框架实现上
【附源码】计算机毕业设计JAVA家庭记账系统
Chisel-Strike：一款功能强大的.NET异或XOR加密CobaltStrike Aggressor实现
Java之JavaConfig
电商小程序实战教程-类别导航续
《现代医学成像科学丛书——CT原理与技术》——X射线管的基本作用
Linux的so组件设计框架及逻辑
netcore项目中的GC模式
【改进灰狼优化算法】基于协调探索和开发能力的改进灰狼优化算法求解单目标优化问题（Matlab代码实现）
应用统计-点估计法（1.矩估计 2.极大似然估计）
- 原文地址：https://blog.csdn.net/m0_67403188/article/details/126080662
