carrywang

> 我也是，我默认context-path为/时，无法达到同样的效果 > 结果发现spring security做匹配的时候，是不会携带context-path做匹配的 > > ```java > // 登录接口 > .antMatchers(HttpMethod.POST, SecurityConstants.LOGIN_WHITELIST).permitAll() > // 指定路径下的资源需要验证了的用户才能访问 > .antMatchers(SecurityConstants.FILTER_ALL).authenticated() > .antMatchers(HttpMethod.DELETE, SecurityConstants.FILTER_ALL).hasRole("ADMIN") > // 其他都放行了 > .anyRequest().permitAll() > ``` >...

过滤器UsernamePasswordFilter最后还是走到了那个继承了UserDetailService中loadByUsername方法中，去查数据库，你一步步跟进去可以看到。

> > 过滤器UsernamePasswordFilter最后还是走到了那个继承了UserDetailService中loadByUsername方法中，去查数据库，你一步步跟进去可以看到。 > >  > 或许我表述的不太清楚,的确最后都调用了loadByUsername方法,可我的意思是进入认证的入口不应该是在Filter(图中绿色)中吗?但demo中却是在请求已经被分发到了相应的controller层方法(图中最右)后才开始进行认证 但是默认实现查数据那部分代码应该也是业务代码了吧，loadByUsername应该是在业务类里面。你还是进入到里面了。 这些拦截器我记得只要有一个可以拦截就可以了，你自己可以实现怎么去拦截，就算你一个拦截器都没过，也会有个默认的匿名拦截器，去拦截，然后处理token，最后都是会那个usernamepasswordtoken上。

+1