@Component
public class CustomFilterInvocationSecurityMetadataSource
implements FilterInvocationSecurityMetadataSource {
private final IResourceService iResourceService;
private final IRoleService iRoleService;
private final AntPathMatcher antPathMatcher = new AntPathMatcher();
private final Map
> requestMap = new HashMap<>();
* 适用于很多线程从一个数据结构读取数据而很少的线程修改其中数据
ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
* 该锁可以被多个读操作共用的读锁，但会排斥写操作
Lock readLock = rwl.readLock();
* 该锁排斥所有其他的读操作和写操作
Lock writeLock = rwl.writeLock();
public CustomFilterInvocationSecurityMetadataSource(IResourceService iResourceService,
IRoleService iRoleService) {
this.iResourceService = iResourceService;
this.iRoleService = iRoleService;
this.loadResourcePermission();
* 加载权限
private void loadResourcePermission() {
writeLock.lock(); //locks all readers and writers
// do write data
log.info("加载权限");
requestMap.clear();
List resources = iResourceService.list();
for (Resource resource : resources) {
List roles = iRoleService.listRoleBySid(resource.getId());
String[] roleArr = new String[roles.size()];
for (int i = 0; i < roleArr.length; i++) {
roleArr[i] = roles.get(i).getName();
requestMap.put(new AntPathRequestMatcher(resource.getPattern()),
SecurityConfig.createList(roleArr));
}finally {
writeLock.unlock();
* 权限重载
public void resetResourcePermission(){
log.info("权限重载");
loadResourcePermission();
@Override
public Collection getAttributes(Object o) throws IllegalArgumentException {
Set attributes = new HashSet<>();
readLock.lock(); //blocks writers only
//there should be data now
final HttpServletRequest request = ((FilterInvocation) o).getRequest();
for (Map.Entry> entry : requestMap
.entrySet()) {
if (entry.getKey().matches(request)) {
attributes.addAll(entry.getValue());
}finally {
readLock.unlock();
// final String requestUrl = ((FilterInvocation) o).getRequestUrl();
// List resources = iResourceService.list();
// Set attributes = new HashSet<>();
// for (Resource resource : resources) {
// if (antPathMatcher.match(resource.getPattern(), requestUrl)) {
// List roles = iRoleService.listRoleBySid(resource.getId());
// if (roles.size() > 0) {
// String[] roleArr = new String[roles.size()];
// for (int i = 0; i < roleArr.length; i++) {
// roleArr[i] = roles.get(i).getName();
// }
// attributes.addAll(SecurityConfig.createList(roleArr));
// }
// }
// }
if (attributes.size() == 0) {
attributes.addAll(SecurityConfig.createList("ROLE_LOGIN"));
return attributes;
@Override
public Collection getAllConfigAttributes() {
Set allAttributes = new HashSet<>();
readLock.lock(); //blocks writers only
for (Map.Entry> entry : requestMap
.entrySet()) {
allAttributes.addAll(entry.getValue());
}finally {
readLock.unlock();
return allAttributes;
@Override
public boolean supports(Class aClass) {
return FilterInvocation.class.isAssignableFrom(aClass);
Spring Boot2 总结(四) Spring Security 动态权限配置
在
Spring
Security
中
实现
通过数据库
动态
配置
url资源
权限
，需要通过
配置
验证过滤器来
实现
资源
权限
的加载、验证。系统启动时，到数据库加载系统资源
权限
列表，当有请求访问时，通过对比系统资源
权限
列表和用户资源
权限
列表（在用户登录时添加到用户信息中）来判断用户是否有该url的访问
权限
。
在
配置
验证过滤器时需要的
配置
项有如下几个：
filter
Security
Interceptor：通过继承Abstract
Security
Interceptor并
实现
Filter
接口自定义一个验证过滤...
前面我们已经
实现
了用户的自定义登录及密码的加密，接下来就是
动态
的
权限
验证了，也就是
实现
Spring
Security
的决策管理器AccessDecis
ion
Manager。
权限
资源
Security
Metadata
Source
要
实现
动态
的
权限
验证，当然要先有对应的访问
权限
资源了。
Spring
Security
是通过
Security
Metadata
Source
来加载访
数据库设计：
首先
配置
Filter
Invo
cat
ion
Security
Metadata
Source
,监听用户的请求，获取请求地址url所需的角色，如果url不存在返回ROLE_LOGIN作为标记。
* 这个
类
的功能，根据用户传来...
一般情况下，我们如果需要自定义
权限
拦截，则需要涉及到
Filter
Invo
cat
ion
Security
Metadata
Source
这个接口了。
这里有个坑爹的地方。如果用户未登录，但是已经设置了拦截白名单的URL，仍然会进入到
权限
验证里面来。起初，我以为不会进来，但后来跟踪源代码发现，还是会进来。只是此时的身份是一个匿名用户。其默认的
实现
为Default
Filter
Invo
cat
ion
Securi...
这样，当用户发起请求时，
Spring
Security
将从
security
Metadata
Source
中获取该请求所需的访问控制元数据，并根据这些元数据进行访问控制。总结来说，
Filter
Invo
cat
ion
Security
Metadata
Source
接口用于获取指定请求所需的访问控制元数据，
实现
类
负责根据请求 URL，从数据库或其他外部数据源中获取相应的访问控制元数据，并将其放置到
Spring
Security
的全局缓存中供后续使用。
权限
管理相关概念
权限
管理是一个几乎所有后台系统的都会涉及的一个重要组成部分，主要目的是对整个后台管理系统进行
权限
的控制。常见的基于角色的访问控制，其授权模型为“用户-角色-
权限
”，简明的说，一个用户拥有多个角色，一个角色拥有多个
权限
。其中，
用户： 不用多讲，大家也知道了；
角色： 一个集合的概念，角色管理是确定角色具备哪些
权限
的一个过程 ；
1）.页面
权限
，控制你可以看到哪个页...
虽然前面我们
实现
了通过数据库来
配置
用户与角色，但
认证
规则仍然是使用Http
Security
进行
配置
，还是不够灵活，无法
实现
资源和角色之间的
动态
调整。这篇文章我们就介绍一下通过数据库查询某个URL资源的访问角色。
四、基于数据库的URL
权限
规则
配置
1、数据库设计
这里在上一篇文章的基础上再添加 资源表和资源
权限
表 两种数据表，表结构如下所示：
资源表，保存每个菜单的URL
CREATE TABLE `menus` (
`id` bigint(20) unsigned NOT NULL ...
谨记：Url表只储存受保护的资源，不在表里的资源说明不受保护，任何人都可以访问
1、My
Filter
Invo
cat
ion
Security
Metadata
Source
类
判断该访问路径是否被保护
@Component
//用于设置受保护资源的
权限
信息的数据源
public class My
Filter
Invo
cat
ion
Security
Metadata
Source
implements
Filter
Invo
cat
ion
Security
Metadata
Source
{
@Bean
Spring
Security
进行的
权限
验证，有时候可能并不太满足我们的需求。有时候呢可能需要你自己去扩展达到一个对自己业务满意的验证，这时候怎么办呢？第一呢， 先不要百度，你要懂
权限
验证的一个流程，不懂的话可以去看我之前的博客，第二呢，就是放开手按照自己假象的思路去实践！
我说一下我的需求，我想判断那个角色拥有某些url的
权限
，这时候该怎么进行扩展呢？
我的思路是对 自定义 Acce...
6.1 授权
认证
之前学了身份
认证
，就是
认证
当前登录的用户是否是存在并真实的，身份
认证
成功后就可以访问
认证
后的接口（资源）了，但即便是已
认证
的用户也有能访问不能访问的接口（资源），那么就需要通过授权
认证
来判断。
今天学习授权
认证
，也就是
认证
当前登录用户都有哪些
权限
，并确定当前用户的
权限
是否能访问当前请求的接口。
之前在
spring
security
——学习笔记（day03）-UserDetailsSe...
