@
ourslay URL 没有动态配置。
@
siweipancc 很好的利用 Spring Security 更简单。
@
zhaoxixiangban @
tctc4869 思路：
1， 权限定义用一个表（ JPA Entity ），类似结构：
name 唯一，另外（ urlPattern 与 httpMethod ）组合唯一。
Permission{
name//唯一，比如 PERM_GET_ALL_POSTS
urlPattern//比如：/posts/*
httpMethod// 比如：GET， 可用 enum 或直接用 Spring web HttpMethod. 常用的有 GET,POST,PUT,DELETE,PATCH
longDescription//其它辅助说明（用于页面补充）
}
那么 user 与 Permission 权限关系：
user->permission 1:n
2. Repository 类，PermissionRepository
3. Spring Security 中直接使用 Apply 。
allPermissions= permissionRepository.findAll(
Sort.by(...))
http
.authorizeRequests(authorize ->
allPermissions.forEach(perm->{
authorize
.antMatchers(per.urlPattern, per.httpMethod).hasAuthority(
perm.name)//这里查 Spring Security 文档，我记得以前不用 AntMatcher，而使用 RegexMatcher，表达比 ANT 方式更丰富。
})
4. 配置一个超级管理员，绕过所有权限（不读数据库），可以维护系统的 permission 列表。
默认给定一个管理员，配置所有权限。管理员可以用管理用户，可以管理用户权限（页面可以是 Checkbox，或者两列选择，等），最终影响 user -> permission 关系表。
所有新注册用户默认应该协商好，应该给那些权限，可以设计一些 DUMMY 权限比如 READ，那么在 persmission 表所有 httpmethod GET 权限就拿到了（ UserDetailsService 中转换成实际 permissions 的 Authories ）。
5. （扩展） 所有权限的初始数据可以用 Reflection 生成，在系统启动时初始化(添加，更新)。
6. （扩展） 可以添加 Role，role->Permission 可以是一对多的关系, 相当于权限分组了。在 UserDetailsService 的 findByusername 将所有的 Role 转换成 Permission 添加到 authories 中（因为上面的 Spring Security 中只配置比较 Permission ）。这样的话，数据库关系变成 user->role>permission 1:n,1:n 。
7. （扩展) 所有前端的权限可以登录时拿到一个个人的允许的 permission 列表，可以用来辅助前端的页面控制。比如没有授权 PERM_GET_ALL_POSTS 的时候，可以从页面把顶级菜单上的 posts 去掉了。API 资源本身就是可以归类的，我从来没用过 V 站那些资源共享版本中贴的那些什么功能模块与权限配置表。
我遵循的一个原则，用户细粗度的行为（一个点击，一个操作）在一个应用程序中基本是可以固定下来的。所以 每一个不同操作最终变成一个不同的权限，Permission 在你的项目(应用)上线时候，基本可以是固定下来的，而 Role 完全可以由用户随便添加，随意修改。