一个权限控制问题

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

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

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

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

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

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

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

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

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

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