V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
bler
V2EX  ›  程序员

一个权限控制问题

  •  
  •   bler · 13 天前 · 1759 次点击
    一般场景下,我们都是基于角色进行权限的管理,但是我感觉无法更加精细化权限控制

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

    有大佬还有其他方案吗
    26 条回复    2024-11-30 01:50:21 +08:00
    KongLiu
        1
    KongLiu  
       13 天前   ❤️ 2
    搞一张用户课程表,购买之后往里面插一条数据不行吗,最好不要和订单这种耦合在一起。单独一张表以后你要做有效期这种都好控制
    pigf
        2
    pigf  
       13 天前   ❤️ 1
    数据权限和功能权限
    a33291
        3
    a33291  
       13 天前
    @pigf 对,就像我们不会看到其他人的 jd 订单一样,这是数据权限
    bler
        4
    bler  
    OP
       13 天前
    @pigf 大佬,举一个例子说说
    whoosy
        5
    whoosy  
       13 天前   ❤️ 1
    数据权限校验如果应用内没有成熟的组织架构模型的话,最好还是下沉到业务里面去做,你这个场景,搞一张用户权益表,把购买行为转化为权益记录,后面还可以灵活地管理不同类型的权限
    bler
        6
    bler  
    OP
       13 天前
    大概明白了,功能权限有点类似角色的权限管理,数据权限就是更加细粒度的权限管理,不知道理解的对不对
    COW
        7
    COW  
       13 天前 via Android   ❤️ 1
    谷歌下 rbac+
    bler
        8
    bler  
    OP
       13 天前
    总结一下,大致方案就是另立一张表,然后再 service 中做处理,很好奇一个大项目是如何颗粒化控制这些权限的。
    bler
        9
    bler  
    OP
       13 天前
    有大佬知不知道 github 上,有没有权限控制比较复杂精细的项目,想参考一下别人的权限系统是如何架构的
    soul11201
        10
    soul11201  
       13 天前 via Android   ❤️ 1
    基于属性的 rbac 基于规则的 rbac 云上多租户的 rbac 去知网搜搜论文,去 nist 官网看看 rbac 最新进展,会开阔眼界
    bler
        11
    bler  
    OP
       13 天前
    @COW 感谢大佬,rbac+可能正是我需要的东西
    bler
        12
    bler  
    OP
       13 天前
    @soul11201 谢谢大佬
    bler
        13
    bler  
    OP
       13 天前
    有感而发,有些东西还是需要参考别人的东西。自己搞了一个小破站,一开始搞那个权限控制,搞了一个用户等级和产品等级的东西,让他们在那比较,不经意间刷抖音,看到 RBAC ,了解了一下,才发现自己代码写的有多烂。之前好多东西都糅杂在 service 里面,搞得 service 代码又长,可读性还很差
    soul11201
        14
    soul11201  
       13 天前 via Android   ❤️ 1
    @bler 不需要贬低自己,也不要过于抬高他们。最重要的是已经在认认真真做了,做的事情对他人有益最好,对他人有没什么影响,但自己在这段时光里很开心,不也挺好?
    Ericality
        15
    Ericality  
       12 天前   ❤️ 1
    rbac 可能这个场景更复杂了吧 毕竟其实你不需要授权或者授权组 资源及的概念
    直接写一个权限控制 service 维持一个
    用户信息 资源表 订单表 用户-资源关联表 用户订单关联表
    用户有购买行为时更新关联关系 将对应资源-用户关系插入信息
    如果有涉及到有效期的资源 就起一个定时器 定期根据关系查关联表 然后查用户-订单关联表检查是否过期 过期就删用户-资源关系
    然后每个用户进来直接查询用户-资源关联表就是他可见的资源
    感觉似乎就够了你的场景?
    jonzhao
        16
    jonzhao  
       12 天前
    ABAC ?
    ming159
        17
    ming159  
       12 天前   ❤️ 1
    RBAC 已经相当简洁且强大了....
    用户,角色不多说了. 搞清楚另外 3 个关系,自己实现都非常简单且灵活.

    1. 权限: 就是一个标志,比如用字符串. 可以按照自己系统,任意定义,粒度可以到操作按钮,甚至某个字段的访问.
    2. 鉴权: 对资源进行的操作,如读、写、执行前,先判断当前 用户是否属于某个角色,或者用户本身有没有权限标志符
    3. 授权: 将权限标志,赋予用户,或者角色
    jaylee4869
        18
    jaylee4869  
       12 天前   ❤️ 1
    我自己实现公司项目里的数据权限是在 ORM 层做拦截,把原生的 SQL 做 AST 解析后,拼接一个 where 子句过滤用户能看到的数据。功能权限就是 RBAC 。
    xuanbg
        19
    xuanbg  
       12 天前
    这是一个典型的数据权限控制问题,如 OP 这种需求,是这个授权逻辑写死在 SQL 代码中就行,譬如把结果和用户的订单进行关联。
    xuanbg
        20
    xuanbg  
       12 天前   ❤️ 1
    另外,数据权限是和业务数据紧密关联的,这里的数据,指的就是业务数据。说白了,数据权限就是使用/管理业务数据的权限。所以从理论上就不可能同功能权限一样脱离业务抽象为 RBAC 模型。所以,OP 不用去找什么框架、模型、理论啥的,不可能有的。有的也必然是糊弄人的。正确的做法就是把规则直接写在业务逻辑里面。
    COW
        21
    COW  
       12 天前 via Android
    @bler rbac 只要抓住几个核心不要脱离模型就行了,用户角色权限。其他的需求自己想办法是可以设计进去的,但会增加复杂度,比如引入组概念、额外属性控制、互斥约束,最典型的像 OA 、ERP 这种比较重的系统,光一个 RBAC 是远远不够的。
    jov1
        22
    jov1  
       12 天前   ❤️ 1
    rbac 能解决一部分垂直越权问题,也就是对于接口或其他资源的访问控制, 比如限制某人有某接口、按钮操作、什么什么的权限,但是解决不了水平越权和数据权限问题,比如大家都能看订单,有的希望按照组织架构,级别高的可以看所有子级的,这种有的方案是在对于资源记录所属组织,比如资源上增加该资源所属组织路径,/a/b, 查询时候按照这个过滤,有的是大家都有查看订单权限,如果我通过?orderId=xx 访问一个不是我的订单的详情或者什么数据,这种有些用多租户,就是需要控制数据查看的表都增加租户 id 这样的字段,进行全局 sql 拦截过滤数据,或者不合适多租户需求的业务就根据具体业务写在具体业务代码里,目前我自己是没有找到很通用的关于数据权限的模型或框架工具。
    bler
        23
    bler  
    OP
       12 天前
    @Ericality 确实够了,但是自有项目,有点像玩养成游戏一样,想玩点新花样。一开始我是没有将关系从订单表中独立出来的,并且还是自建了一套用户等级产品等级的一套权限管理方式,但是我发现不独立出来不好搞权限的有效期,以及添加一些新信息,以便有效的管理用户-产品的权限,我就独立出来了。

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

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

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

    但是我感觉差了点什么,感觉这种方案不够体系化
    whoami9426
        24
    whoami9426  
       12 天前
    如何你用 PostgreSQL 可以试试 RLS
    Row level security ,行级安全,允许系统管理员为数据库表创建访问策略( policy ),以约束数据的可见性。当为一个表创建了 policy 后,相当于为该表增加了一个高优先级的过滤器。当用户访问该表时,如果 policy 生效,则会根据 policy 中定义的过滤条件来决定用户可操作的数据集合。
    whoami9426
        25
    whoami9426  
       12 天前
    @whoami9426
    "如何" -> "如果"
    soul11201
        26
    soul11201  
       12 天前
    @jov1
    >有的希望按照组织架构,级别高的可以看所有子级的,
    你这是没玩明白 RBAC ,RBAC 的核心要义在偏序结构,你可以把组织架构定义成一颗权限树。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5563 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 02:39 · PVG 10:39 · LAX 18:39 · JFK 21:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.