1
KongLiu 7 天前 2
搞一张用户课程表,购买之后往里面插一条数据不行吗,最好不要和订单这种耦合在一起。单独一张表以后你要做有效期这种都好控制
|
2
pigf 7 天前 1
数据权限和功能权限
|
5
whoosy 7 天前 1
数据权限校验如果应用内没有成熟的组织架构模型的话,最好还是下沉到业务里面去做,你这个场景,搞一张用户权益表,把购买行为转化为权益记录,后面还可以灵活地管理不同类型的权限
|
6
bler OP 大概明白了,功能权限有点类似角色的权限管理,数据权限就是更加细粒度的权限管理,不知道理解的对不对
|
7
COW 7 天前 via Android 1
谷歌下 rbac+
|
8
bler OP 总结一下,大致方案就是另立一张表,然后再 service 中做处理,很好奇一个大项目是如何颗粒化控制这些权限的。
|
9
bler OP 有大佬知不知道 github 上,有没有权限控制比较复杂精细的项目,想参考一下别人的权限系统是如何架构的
|
10
soul11201 7 天前 via Android 1
基于属性的 rbac 基于规则的 rbac 云上多租户的 rbac 去知网搜搜论文,去 nist 官网看看 rbac 最新进展,会开阔眼界
|
13
bler OP 有感而发,有些东西还是需要参考别人的东西。自己搞了一个小破站,一开始搞那个权限控制,搞了一个用户等级和产品等级的东西,让他们在那比较,不经意间刷抖音,看到 RBAC ,了解了一下,才发现自己代码写的有多烂。之前好多东西都糅杂在 service 里面,搞得 service 代码又长,可读性还很差
|
14
soul11201 7 天前 via Android 1
@bler 不需要贬低自己,也不要过于抬高他们。最重要的是已经在认认真真做了,做的事情对他人有益最好,对他人有没什么影响,但自己在这段时光里很开心,不也挺好?
|
15
Ericality 7 天前 1
rbac 可能这个场景更复杂了吧 毕竟其实你不需要授权或者授权组 资源及的概念
直接写一个权限控制 service 维持一个 用户信息 资源表 订单表 用户-资源关联表 用户订单关联表 用户有购买行为时更新关联关系 将对应资源-用户关系插入信息 如果有涉及到有效期的资源 就起一个定时器 定期根据关系查关联表 然后查用户-订单关联表检查是否过期 过期就删用户-资源关系 然后每个用户进来直接查询用户-资源关联表就是他可见的资源 感觉似乎就够了你的场景? |
16
jonzhao 7 天前
ABAC ?
|
17
ming159 7 天前 1
RBAC 已经相当简洁且强大了....
用户,角色不多说了. 搞清楚另外 3 个关系,自己实现都非常简单且灵活. 1. 权限: 就是一个标志,比如用字符串. 可以按照自己系统,任意定义,粒度可以到操作按钮,甚至某个字段的访问. 2. 鉴权: 对资源进行的操作,如读、写、执行前,先判断当前 用户是否属于某个角色,或者用户本身有没有权限标志符 3. 授权: 将权限标志,赋予用户,或者角色 |
18
jaylee4869 7 天前 1
我自己实现公司项目里的数据权限是在 ORM 层做拦截,把原生的 SQL 做 AST 解析后,拼接一个 where 子句过滤用户能看到的数据。功能权限就是 RBAC 。
|
19
xuanbg 7 天前
这是一个典型的数据权限控制问题,如 OP 这种需求,是这个授权逻辑写死在 SQL 代码中就行,譬如把结果和用户的订单进行关联。
|
20
xuanbg 7 天前 1
另外,数据权限是和业务数据紧密关联的,这里的数据,指的就是业务数据。说白了,数据权限就是使用/管理业务数据的权限。所以从理论上就不可能同功能权限一样脱离业务抽象为 RBAC 模型。所以,OP 不用去找什么框架、模型、理论啥的,不可能有的。有的也必然是糊弄人的。正确的做法就是把规则直接写在业务逻辑里面。
|
21
COW 7 天前 via Android
@bler rbac 只要抓住几个核心不要脱离模型就行了,用户角色权限。其他的需求自己想办法是可以设计进去的,但会增加复杂度,比如引入组概念、额外属性控制、互斥约束,最典型的像 OA 、ERP 这种比较重的系统,光一个 RBAC 是远远不够的。
|
22
jov1 7 天前 1
rbac 能解决一部分垂直越权问题,也就是对于接口或其他资源的访问控制, 比如限制某人有某接口、按钮操作、什么什么的权限,但是解决不了水平越权和数据权限问题,比如大家都能看订单,有的希望按照组织架构,级别高的可以看所有子级的,这种有的方案是在对于资源记录所属组织,比如资源上增加该资源所属组织路径,/a/b, 查询时候按照这个过滤,有的是大家都有查看订单权限,如果我通过?orderId=xx 访问一个不是我的订单的详情或者什么数据,这种有些用多租户,就是需要控制数据查看的表都增加租户 id 这样的字段,进行全局 sql 拦截过滤数据,或者不合适多租户需求的业务就根据具体业务写在具体业务代码里,目前我自己是没有找到很通用的关于数据权限的模型或框架工具。
|
23
bler OP @Ericality 确实够了,但是自有项目,有点像玩养成游戏一样,想玩点新花样。一开始我是没有将关系从订单表中独立出来的,并且还是自建了一套用户等级产品等级的一套权限管理方式,但是我发现不独立出来不好搞权限的有效期,以及添加一些新信息,以便有效的管理用户-产品的权限,我就独立出来了。
接触到 RBAC 后,我废弃了自有那套用户等级,产品等级那套东西,改用用户组,权限,用户,采用给用户组授权,将用户添加到用户组的方式,实现权限管理,代码简洁了很多 但是这套权限管理好像不够精细,比如给产品一个种类,然后添加一个用户组,给这个用户组授权访问这类产品的权限,当我想给“用户到具体某一个产品”添加权限的时候,发现采用用户组这种方式,产品表越大,定义的权限就越多,权限表就会变大 事情又回到开始了,我能想到的是从订单表中独立出 一张表,管理“用户具体到某一个产品“的权限。 但是我感觉差了点什么,感觉这种方案不够体系化 |
24
whoami9426 7 天前
如何你用 PostgreSQL 可以试试 RLS
Row level security ,行级安全,允许系统管理员为数据库表创建访问策略( policy ),以约束数据的可见性。当为一个表创建了 policy 后,相当于为该表增加了一个高优先级的过滤器。当用户访问该表时,如果 policy 生效,则会根据 policy 中定义的过滤条件来决定用户可操作的数据集合。 |
25
whoami9426 7 天前
@whoami9426
"如何" -> "如果" |