一个权限控制问题

[bler]

一般场景下，我们都是基于角色进行权限的管理，但是我感觉无法更加精细化权限控制

比如在一个知识付费场景，用户只有购买了对应的产品才能查看产品的具体内容，我能想到的是基于订单的购买记录进行权限控制。

有大佬还有其他方案吗

[KongLiu]

搞一张用户课程表，购买之后往里面插一条数据不行吗，最好不要和订单这种耦合在一起。单独一张表以后你要做有效期这种都好控制

[pigf]

数据权限和功能权限

[a33291]

@pigf 对,就像我们不会看到其他人的 jd 订单一样,这是数据权限

[bler]

@pigf 大佬，举一个例子说说

[whoosy]

数据权限校验如果应用内没有成熟的组织架构模型的话，最好还是下沉到业务里面去做，你这个场景，搞一张用户权益表，把购买行为转化为权益记录，后面还可以灵活地管理不同类型的权限

[bler]

大概明白了，功能权限有点类似角色的权限管理，数据权限就是更加细粒度的权限管理，不知道理解的对不对

[COW]

谷歌下 rbac+

[bler]

总结一下，大致方案就是另立一张表，然后再 service 中做处理，很好奇一个大项目是如何颗粒化控制这些权限的。

[bler]

有大佬知不知道 github 上，有没有权限控制比较复杂精细的项目，想参考一下别人的权限系统是如何架构的

[soul11201]

基于属性的 rbac 基于规则的 rbac 云上多租户的 rbac 去知网搜搜论文，去 nist 官网看看 rbac 最新进展，会开阔眼界

[bler]

@COW 感谢大佬，rbac+可能正是我需要的东西

[bler]

@soul11201 谢谢大佬

[bler]

有感而发，有些东西还是需要参考别人的东西。自己搞了一个小破站，一开始搞那个权限控制，搞了一个用户等级和产品等级的东西，让他们在那比较，不经意间刷抖音，看到 RBAC ，了解了一下，才发现自己代码写的有多烂。之前好多东西都糅杂在 service 里面，搞得 service 代码又长，可读性还很差

[soul11201]

@bler 不需要贬低自己，也不要过于抬高他们。最重要的是已经在认认真真做了，做的事情对他人有益最好，对他人有没什么影响，但自己在这段时光里很开心，不也挺好？

[Ericality]

rbac 可能这个场景更复杂了吧 毕竟其实你不需要授权或者授权组 资源及的概念
直接写一个权限控制 service 维持一个
用户信息 资源表 订单表 用户-资源关联表 用户订单关联表
用户有购买行为时更新关联关系 将对应资源-用户关系插入信息
如果有涉及到有效期的资源 就起一个定时器 定期根据关系查关联表 然后查用户-订单关联表检查是否过期 过期就删用户-资源关系
然后每个用户进来直接查询用户-资源关联表就是他可见的资源
感觉似乎就够了你的场景?

[jonzhao]

ABAC ?

[ming159]

RBAC 已经相当简洁且强大了....
用户,角色不多说了. 搞清楚另外 3 个关系,自己实现都非常简单且灵活.

1. 权限: 就是一个标志,比如用字符串. 可以按照自己系统,任意定义,粒度可以到操作按钮,甚至某个字段的访问.
2. 鉴权: 对资源进行的操作，如读、写、执行前,先判断当前 用户是否属于某个角色,或者用户本身有没有权限标志符
3. 授权: 将权限标志,赋予用户,或者角色

[jaylee4869]

我自己实现公司项目里的数据权限是在 ORM 层做拦截，把原生的 SQL 做 AST 解析后，拼接一个 where 子句过滤用户能看到的数据。功能权限就是 RBAC 。

[xuanbg]

这是一个典型的数据权限控制问题，如 OP 这种需求，是这个授权逻辑写死在 SQL 代码中就行，譬如把结果和用户的订单进行关联。

[xuanbg]

另外，数据权限是和业务数据紧密关联的，这里的数据，指的就是业务数据。说白了，数据权限就是使用/管理业务数据的权限。所以从理论上就不可能同功能权限一样脱离业务抽象为 RBAC 模型。所以，OP 不用去找什么框架、模型、理论啥的，不可能有的。有的也必然是糊弄人的。正确的做法就是把规则直接写在业务逻辑里面。

[COW]

@bler rbac 只要抓住几个核心不要脱离模型就行了，用户角色权限。其他的需求自己想办法是可以设计进去的，但会增加复杂度，比如引入组概念、额外属性控制、互斥约束，最典型的像 OA 、ERP 这种比较重的系统，光一个 RBAC 是远远不够的。

[jov1]

rbac 能解决一部分垂直越权问题，也就是对于接口或其他资源的访问控制， 比如限制某人有某接口、按钮操作、什么什么的权限，但是解决不了水平越权和数据权限问题，比如大家都能看订单，有的希望按照组织架构，级别高的可以看所有子级的，这种有的方案是在对于资源记录所属组织，比如资源上增加该资源所属组织路径,/a/b, 查询时候按照这个过滤，有的是大家都有查看订单权限，如果我通过?orderId=xx 访问一个不是我的订单的详情或者什么数据，这种有些用多租户，就是需要控制数据查看的表都增加租户 id 这样的字段，进行全局 sql 拦截过滤数据，或者不合适多租户需求的业务就根据具体业务写在具体业务代码里，目前我自己是没有找到很通用的关于数据权限的模型或框架工具。

[bler]

@Ericality 确实够了，但是自有项目，有点像玩养成游戏一样，想玩点新花样。一开始我是没有将关系从订单表中独立出来的，并且还是自建了一套用户等级产品等级的一套权限管理方式，但是我发现不独立出来不好搞权限的有效期，以及添加一些新信息，以便有效的管理用户-产品的权限，我就独立出来了。

接触到 RBAC 后，我废弃了自有那套用户等级，产品等级那套东西，改用用户组，权限，用户，采用给用户组授权，将用户添加到用户组的方式，实现权限管理，代码简洁了很多

但是这套权限管理好像不够精细，比如给产品一个种类，然后添加一个用户组，给这个用户组授权访问这类产品的权限，当我想给“用户到具体某一个产品”添加权限的时候，发现采用用户组这种方式，产品表越大，定义的权限就越多，权限表就会变大

事情又回到开始了，我能想到的是从订单表中独立出 一张表，管理“用户具体到某一个产品“的权限。

但是我感觉差了点什么，感觉这种方案不够体系化

[whoami9426]

如何你用 PostgreSQL 可以试试 RLS
Row level security ，行级安全，允许系统管理员为数据库表创建访问策略（ policy ），以约束数据的可见性。当为一个表创建了 policy 后，相当于为该表增加了一个高优先级的过滤器。当用户访问该表时，如果 policy 生效，则会根据 policy 中定义的过滤条件来决定用户可操作的数据集合。

[whoami9426]

@whoami9426
"如何" -> "如果"

[soul11201]

@jov1
>有的希望按照组织架构，级别高的可以看所有子级的，
你这是没玩明白 RBAC ，RBAC 的核心要义在偏序结构，你可以把组织架构定义成一颗权限树。