Spring Security 的 antMatchers() 过滤级别

http.authorizeRequests().antMatchers("/static/**")和.antMatchers("/static/*")在匹配URL上有一些区别。

.antMatchers("/static/**")：这个模式表示以/static/开头的路径及其子路径，例如 "/static/css/style.css"、"/static/js/main.js" 等。

通配符**匹配任意层级的子路径。 .antMatchers("/static/*")：这个模式表示以/static/开头的路径下的直接子路径，不包括子路径的子路径，例如 /static/css、/static/js等。 如果你希望匹配到/static/下的所有子路径，使用.antMatchers("/static/**")； 如果只需要匹配到/static/下的直接子路径，而不包括子路径的子路径，则可以使用.antMatchers("/static/*")。

---

Spring Security 的 hasRole & hasAuthority 的区别

1http.authorizeRequests()
2.antMatchers("/admin/").hasAuthority("admin")
3.antMatchers("/user/").hasAuthority("user")
4及
5http.authorizeRequests()
6.antMatchers("/admin/").hasRole("admin")
7.antMatchers("/user/").hasRole("user")

hasRole的处理逻辑和hasAuthority似乎一模一样，不同的是，hasRole这里会自动给传入的字符串加上ROLE_前缀，所以在数据库中的权限字符串需要加上ROLE_前缀。即数据库中存储的用户角色如果是ROLE_admin，这里就是 admin。

我们在调用hasAuthority方法时，如果数据是从数据库中查询出来的，这里的权限和数据库中保存一致即可，可以不加ROLE_前缀。即数据库中存储的用户角色如果是 admin，这里就是 admin。

也就是说，使用hasAuthority更具有一致性，你不用考虑要不要加ROLE_前缀，数据库什么样这里就是什么样！而hasRole则不同，代码里如果写的是 admin，框架会自动加上ROLE_前缀，所以数据库就必须是 ROLE_admin。

看起来hasAuthority和hasRole的区别似乎仅仅在于有没有ROLE_前缀。

---

整合 Security 报错

1org.mybatis.spring.MyBatisSystemException: nested exception is org.apache.ibatis.reflection.ReflectionException: Illegal overloaded getter method with ambiguous type for property enabled in class class com.springboot.security.entity.User. This breaks the JavaBeans specification and can cause unpredictable results.

原因：在做用户登录的时候，通常我们会判断当前账号是否可用，将这个属性设置为Boolean类型。而我们定义好的类需要实现UserDetails接口来规范用户属性，然后重写里面的方法来判断当前的用户是否可用。这时候重写的isEnabled方法就会跟 Mybatis 自动生成的getEnabled方法同时存在。

解决方法：因为isEnable相当于getEnable，导致 JavaBean 里面有两个getEnabled方法，违反了 JavaBean 的规范，只要将其中一个删掉就可以了。