一个权限控制问题

[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 不用去找什么框架、模型、理论啥的，不可能有的。有的也必然是糊弄人的。正确的做法就是把规则直接写在业务逻辑里面。