spring-security，有没有对需要权限控制的 url 存入数据库的实现。

• 資深大佬 : admin7785

  考虑过这个问题，基于链接的授权：
  1. Spring Security 中设置所有 (某些) 链接都需要角色 USER 才能访问
  2. AuthenticationFilter 获取用户登录信息时 (基于 token) 查询用户是否可以访问此链接，如果可以设置角色为 USER 使得其有权访问，否则设置为没有权限的用户角色如 NO 即可

• 資深大佬 : jorneyr

  你这个，可以用 PreAuth 注解，在 el 引用一个 验证 bean 对现有凭据进行拦截。我待会写一个 demo 看看。

• 資深大佬 : siweipancc

  。。。不就是接口级权限么，网上实现应该很多啊。spring security 里有授权管理器，自己重写一遍覆盖掉默认的就行了

• 資深大佬 : skypyb

  实现不难，但是完全没必要。国内很多需求都是扯蛋的，一般项目几种 Role 就基本可以了。

  以前一个项目，客户要求实现自己 一套颗粒度很细的权限管理，自己可以编辑配置。实现过程要花点时间，难度不大，全部（ API 的 URLPattern，HTTPMETHOD，一条不同操作对应一条授权 Permission ）保存到数据库，用户页面可以打开授权，整页面都是 CheckBox 的 Permissions，客户看到那个后自己都晕了，感觉自己蠢了。

• 資深大佬 : hantsy

  https://docs.spring.io/spring-security/site/docs/5.4.0-M1/reference/html5/#el-access-web-beans
  `
  public class WebSecurity {
  public boolean check(Authentication authentication, HttpServletRequest request) {
  …
  }
  }
  You could refer to the method using:

  <http>
  <intercept-url pattern=”/user/**”
  access=”@webSecurity.check(authentication,request)”/>
  …
  </http>
  or in Java configuration

  http
  .authorizeRequests(authorize -> authorize
  .antMatchers(“/user/**”).access(“@webSecurity.check(authentication,request)”)
  …
  )
  `
  Reactive 应用就更简单
  `
  public SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) {
  http
  .authorizeExchange()
  .pathMatchers(“/api/**”).access(customerAccessCheck)
  …
  return http.build();
  }
  `

• 資深大佬 : ourslay

  // ———model
  @Entity
  @Data
  @Accessors(chain = true)
  public class AuthUrl implements Serializable {
  @Id
  @GeneratedValue
  private Long id;

  private String url;

  @ElementCollection
  private List<Long> uIds;
  }

  // —– 控制层 @PreAuthorize(“@userProfileManager.currentUserAuthForUlr(authentication,httpServletRequest.requestURL.toString())”)
  @PutMapping(“password”)
  public ResponseEntity<String> changePassword(@RequestParam String newPassword, Authentication authentication) {
  profileManager.changePassword(newPassword, authentication);
  return ResponseEntity.ok(“success”);
  }

  // ——– service
  public class UserProfileManager {
  // 各种注入
  public boolean currentUserAuthForUlr(Authentication authentication, String url) {
  Optional<UserProfile> optional = userProfileMapper.findOne(Example.of(new UserProfile().setEmail(authentication.getPrincipal().toString())));
  UserProfile profile = optional.orElseThrow(() -> new BadCredentialsException(“请重新登录”));
  AuthUrl authUrl = authUrlMapper.findOne(Example.of(new AuthUrl().setUrl(url))).orElse(null);
  if (authUrl == null) {
  return true;
  }
  List<Long> uIds = authUrl.getUIds();
  return uIds == null || uIds.isEmpty() || uIds.contains(profile.getId());
  }

  public void changePassword(String newPassword, Authentication authentication) {
  Optional<UserProfile> optional = userProfileMapper.findOne(Example.of(new UserProfile().setEmail(authentication.getPrincipal().toString())));
  UserProfile profile = optional.orElseThrow(() -> new BadCredentialsException(“请重新登录”));
  String encode = passwordEncoder.encode(newPassword);
  profile.setPassword(encode);
  userProfileMapper.saveAndFlush(profile);
  }
  // **
  }

• 資深大佬 : siweipancc

  @hantsy 你的权限系统的思路，能说明一下么？

• 資深大佬 : tctc4869

  @skypyb #4 需要前端进行自定义配置角色权限的，类似五的需求。- -· 汗 ，所以需要把可配置的权限都给到前端

• 主 資深大佬 : zhaoxixiangban

  目测 xy problem

• 資深大佬 : Vegetable

  @siweipancc #7 嗯 现在后台权限这边问题不大，像上面五说的类似，需要用户对细粒度的权限进行自定义配置，就需要我们把相应的接口数据都存起来给前端,接口列表数据这部分都是怎么实现的呢？手动加数据库？

• 主 資深大佬 : zhaoxixiangban

  @hantsy #5 对就是这种需求 ，操作接口是自己手动加数据库吗

• 主 資深大佬 : zhaoxixiangban

  @jorneyr #2
  @ourslay #6
  抱歉是我没有说清楚 ，问题点是五阐述的这种状况。

• 主 資深大佬 : zhaoxixiangban

  @admin7785 #1 具体怎么个搞法

• 主 資深大佬 : zhaoxixiangban

  @zhaoxixiangban 我建议你不要这么玩，最后双头坑，角色或者组跟模块绑定的设计才能继续维护。

• 資深大佬 : siweipancc

  手动加数据库，然后加载权限信息到用户，最后配置全局权限控制；

• 資深大佬 : daimubai

  看一下我的实现，可能有 bug，不过可以借鉴一下。https://github.com/chenzhenjia/niubi-commons/blob/master/README.md
• 資深大佬 : zhenjiachen

  @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 完全可以由用户随便添加，随意修改。

• 資深大佬 : hantsy

  user->permission，user->role>permission 应该都是 n:m 多对多。

• 資深大佬 : hantsy

  回到之前的观点：完全没必要这样灵活设计。之前加了 ROLE 之后 ，ROLE A 包含了 perm a, ROLE B 没有包含 perm a 。那么问题，遇到客户一个用户添加了 A,B，它觉得莫名其妙的来了，为什么 ROLE B 没有 perm a，我（用户）却有 perm a 。那么更复杂的问题来了，当一个用户设置了 ROLE, A，B，C，D，那么是不是要用户去决定 A，B，C，D 之间的权限是继承还是覆盖关系？？？

  这种灵活设计，对用户和开发人员都是作茧自缚，用处不大，技术没含量，很费事。基本过去十几年的项目经验可以肯定的说，基本上都是可以固定的 ROLE 搞定，结果大量的时间去开发所有权限系统。为什么用户会强调 ROLE 要灵活配置，说白了一点，从需求角度来分析，就是它自己需求不确定，不知道要做什么东西。

• 資深大佬 : hantsy

  看 keycloak 的细粒度权限控制

• 資深大佬 : zzl22100048

  @zzl22100048 Keycloak 推荐过好多次了。国内没几个人用的，在 V 站看到的人都是觉得自己开发的权限 /安全系统最好的。

• 資深大佬 : hantsy

  @hantsy 问一下，ABAC 与 RBAC 两种权限模型，有什么本质区别么？没用过 ABAC 权限模型，我目前接触到的权限体系就是关于 RBAC 的，有博客说 ABAC 的权限配置比 RBAC 更灵活，配置权限也更复杂。到底是怎么样的呢？

• 資深大佬 : tctc4869

  @hantsy 浏览了很多有关权限系统的说明博客，关于 ABAC 权限体系，如果要在用途归纳起来，我感觉就是基于平台应用级别的权限系统，不同的组织，在这个平台上，可以有不一样的权限体系。至少每个组织对内权限体系，可以不一样。而 RBAC 权限模型做不到这一点，或者说很困难，至少如果有两个客户群体对内有不一样的权限需求，RBAC 实现起来就会很困难。是这样的么？比如做一个面向多企业客户级别的平台应用，那么权限系统采用 ABAC 是最合适的么

• 資深大佬 : tctc4869

  这个自己 Google 下吧，https://www.dnsstuff.com/rbac-vs-abac-access-control#rbac-vs-abac
  我只关注过 RBAC，似乎 Java EE 标准体系也只有基于 ROLE （和 Group，同等 ROLE ）的设计。

• 資深大佬 : hantsy

  ABAC 看介绍这只是更细一些，而且是另外一个方向。
  RBAC 以 ROLE，行为（权限）为基础的。

  ABAC 更的多关注对一个资源的个别属性的访问控制权限，更细的控制。这个除非是基于传统数据模型的的开发，比如传统的 MIS 之类的系统。我觉得用在 API 的控制不大可能 。传统基于数据的开发，实现也不难。以前的 JBoss 下的 http://picketlink.org/ 应该相应的方案，记得见过了。数据模型，比如 JPA Entity，每个属性用某个 Annotation 标注，全部运行时可以提取出来 ，一样可以存放在数据库或者基于 LDAP 这种层层目录访问的方式 ，然后剩下就是就是在数据 CRUD 操作下控制了。

• 資深大佬 : hantsy

  @tctc4869 很多时候面对客户，只是把有些东西在脑子里面想得太复杂。中国人这种细粒度的控制，说白了也是我们文化的一部分，控制欲太强了。国外角色更多是系统上的分工，国内的讲权限（实际国内客户很少跟谈角色这个词，很多没有角色这个概念）更多的讲操控上的权力，可以授权，可以取消授权。

  其实只要弄清楚，归类出来有几种人可以用这个系统（应用），角色就可以满足。欧美的项目我做很多，有电商，有支付，没有一个要这个种权限配置系统 。有些项目，人家一开始需求就很明确的提出了有几种人用这个系统，操作方式上有应该什么差别。

• 資深大佬 : hantsy

  @hantsy 那我有另一个问题，如果有一个项目，要面向不同类型的客户群体，而且可能每个客户群体内部有不一样的权限需求。这个时候权限系统要怎么配置，若是在 rbac 权限体系下，是进行角色分类上的不同的客户关系扩展，还在重新做针对客户需求的一套应用？还是用 abac 模型体系下设计呢？

• 資深大佬 : tctc4869

  业务相关的权限本身就和开公的一些权限标准（规范等）没太大的关系，自己根据业务需求决定了。