讨论数据权限

2009-05-12 05:14:43 2.5k 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

【D3S】数据权限 - 基于Mybatis的数据权限拦截器实现目录一、背景二、动机三、实现思路3.1 权限类型、操作类型3.2 统一用户及数据权限集合模型3.3 定义数据权限拦截注解3.4 提取配置属性3.5 数据权限拦截器实现四、集成方式五、关于D3S 一、背景最近一直在做RBAC相关的架构设计与实现，传统的RBAC的权限控制只是控制到REST接口（url）、具体方法（权限码）等，而通常实际业务场景还需要对数据权限进行控制，例如：用户仅允许查询自己的用户信息，不允许查询其他人的用户信息用户仅被允许查询同部门或同部门及子部门的用户信息用户仅允许查询指阅读详情

大多应用系统中会有如下需求：
1、普通员工可以对自己建立的业务对象有权限，而上级对所有下级建立的业务对象有权限；
2、员工A对区域A的业务对象有权限，员工B对区域B的业务对象有权限；
3、领导A可以看所有销售纪录，而大领导只关心金额超过1000K的销售纪录；
... ...

这些应该都属于数据权限的范畴，如何来抽象、设计和实现才能够尽可能灵活高效？
不讨论功能权限
Thanks

...全文

34 python 时间和日期介绍python里时间和日期的常用方法，以及案例，还有注意事项。阅读详情

Little_qd

Java 51,407 成员 86,132 内容

+ 关注 + 加入社区

切换为时间正序

lf_java 2012-09-29

打赏
举报

讨论很激烈，学习了俄！

tamade12345678 2012-01-25

打赏
举报

数据权限控制要做的灵活通用还真比较难

dcriori 2009-12-08

打赏
举报

[Quote=引用 32 楼 tomato2088 的回复:]
引用 31 楼 my145794 的回复:
我做的用户权限一般通过在数据库中增加权限字段来实现

哈哈，允许你修改数据库增加字段的场景有多少？
加了字段自动就能保护数据吗？哈哈

如果允许你加字段，500张表你一个一个都加吗？哈哈

维护数据表结构，意味着影响所有生产系统停止生产！！！！
你这种办法也能采用，你们做决策的肯定是吃屎长大的！！
意味着不能扩展维护，还要生产系统都停下来让你修改表结构！
[/Quote]
加字段没有你说的那么可怕吧？如果你做的系统连这都做不到，这系统。。。。。。。

town365 2009-11-26

打赏
举报

权限就是“权”和“限”。“权”就是软件的能作什么，“限”就是权的范围。不要听什么狗屁教科书上的“功能权限”“数据权限”那是直接从DATA 和FUNCTION翻译的。没有道理，连中国字都不懂什么意思——“权限”是权和限的统称。我很反对一些晦涩难懂的说法。请参考我的BLOG：
http://zhaozhenguo.blshe.com/post/925/471185

快乐的2 2009-10-21

打赏
举报

数据权限是指什么？
从上到下看的稀里糊涂。

Little_qd 2009-05-15

打赏
举报

[Quote=引用 44 楼 tomato2088 的回复:]
数据字典 + AOP
不会牺牲性能.
AOP 事前装备负责对数据的操作拦截,
AOP 事后装备负责对结果集进行拦截,可以动态增加原始的查询条件,从最原始层进行过滤.
比如: 动态给一个Hibernate查询增加条件,那查询结果就是符合权限的数据集合.
不用写任何代码.
不用依赖数据库表.
权限系统是独立于应用的.
感觉来这里的都不具备讨论这个的基础! 不要浪费时间了!
[/Quote]

嗯，有点感觉，讨论一些非即时技术问题，很少会有人参与,深入不下去:(

SINCE1978 2009-05-14

打赏
举报

哪位用户不能对什么数据做什么操作这个也可以叫做反权限，在宫力的书里讲过jaas没有反权限因为正反权限共存将使复杂性大增而且实用价值不大。

另外也别再想在数据权中再添加个类似角色的东东了，因为功能权就解决了大部分访问控制，常见系统有此控制机制足矣。只是在客户后期使用时期如果要添加控制谁不能访问什么（这个可能比较常见）的时候，可以用数据权来补充解决，因为此时的功能权限做这件事很别扭。

SINCE1978 2009-05-14

打赏
举报

参与抛砖、上述的：
“功能权，解决谁能够做什么的问题。
数据权，解决谁能够在什么对象上做什么的问题。 ”

——功能权是识别谁能够做什么，实际使用当中由于有角色这个集中点，使得对多个用户分配多项权限更方便。
但是楼主说的数据权范畴之中没有角色这么一个“集中点”，如果还是和功能权一样“解决谁能够在什么对象上做什么”这样势必使得实现出来的系统使用上过于累赘，如果用户数量很多你可以想象必须对所有用户一个个分配数据权限、而且数据权限最基本也得分为对数据的增删改查四项，对一个数据对象一个用户至少得做四项配置...我认为应该把数据权限的定义改为：
数据权，标识谁不能在什么对象上做什么的问题
这样数据权限的内涵完全变了，要以功能权为主数据权为辅，数据权仅仅用于补充，也就是配置哪位用户不能对什么数据做什么操作。

“用户可以属于多个组、多个角色”——属于多个组的实用意义似乎不大，国内的组织结构也少见这样，不如使系统能够绕过角色直接将某权限配机用户功能实用。

另外：数据权限已经和具体数据相关联了，而这个数据必然是在我们的权限系统之外由客户在使用系统期间录入的某些数据，这就已经超出了“通用”权限系统的范畴，引入新的复杂性。

duanjianbo26 2009-05-14

打赏
举报

[Quote=引用 32 楼 tomato2088 的回复:]
引用 31 楼 my145794 的回复:
我做的用户权限一般通过在数据库中增加权限字段来实现

哈哈，允许你修改数据库增加字段的场景有多少？
加了字段自动就能保护数据吗？哈哈

如果允许你加字段，500张表你一个一个都加吗？哈哈

维护数据表结构，意味着影响所有生产系统停止生产！！！！
你这种办法也能采用，你们做决策的肯定是吃屎长大的！！
意味着不能扩展维护，还要生产系统都停下来让你修改表结构！
[/Quote]
说话太难听了，那有种你设计一套完全不用数据库的权限系统啊

Landor2004 2009-05-14

打赏
举报

用户--组--角色--功能--功能中各种操作的控制
按位&运算可以简单的实现功能权限管理，这是一个很成熟的方法，限制就是根据机器的位数限制了功能个数，比如32位的机器有32个，增、删、改、查......，不过似乎这种功能很少

对于部门业务数据控制方面，涉及到数据的安全性，我这边曾经做个项目，方案和jinxfei说的类似，用组绑定

对于领导数据检索统计方面，属于一个综合的子系统：领导查询。这是一个很复杂的业务系统，给领导做决策支持用的，最好别和权限混到一起

duanjianbo26 2009-05-14

打赏
举报

那用户，角色，组，权限之间的关系又如何呢？
用户-角色-权限，这个比较常用，但用户和组呢？
用户-组-权限，组跟角色又是什么关系？

Little_qd 2009-05-14

打赏
举报

[Quote=引用 25 楼 jinxfei 的回复:]
引用 23 楼 Little_qd 的回复:
你的观点和我的期望并没有冲突
正如你说业务对象实例是动态变化，数据权限是一种业务概念
但是数据权限同样很灵活，不拘泥于某一种形态
所以我想讨论是否有一种模型或者实现可以满足这种灵活的控制，而不是硬编码为一种特定的业务逻辑
我觉得你先要作出一个定义，在你的系统中，什么算数据？
还是说连数据是什么都在“可灵活定义”的范畴？
[/Quote]
我感觉
诚然业务对象的实例数据是动态的
但可以通过某个特性来界定一组数据
这个特性可以作为一个应用的场景
操作主体对那些场景拥有权限是可以约定的－－这相当于数据权限规则
实际操作业务数据之前需要根据数据权限规则进行过滤控制－－－这是数据权限
当否？

withoutme_hw 2009-05-14

打赏
举报

gahyyai 2009-05-14

打赏
举报

mark

tomato2088 2009-05-14

打赏
举报

数据字典 + AOP
不会牺牲性能.
AOP 事前装备负责对数据的操作拦截,
AOP 事后装备负责对结果集进行拦截,可以动态增加原始的查询条件,从最原始层进行过滤.
比如: 动态给一个Hibernate查询增加条件,那查询结果就是符合权限的数据集合.

不用写任何代码.
不用依赖数据库表.

权限系统是独立于应用的.

感觉来这里的都不具备讨论这个的基础! 不要浪费时间了!

Little_qd 2009-05-14

打赏
举报

[Quote=引用 40 楼 SINCE1978 的回复:]
参与抛砖、上述的：
“功能权，解决谁能够做什么的问题。
数据权，解决谁能够在什么对象上做什么的问题。 ”

——功能权是识别谁能够做什么，实际使用当中由于有角色这个集中点，使得对多个用户分配多项权限更方便。
但是楼主说的数据权范畴之中没有角色这么一个“集中点”，如果还是和功能权一样“解决谁能够在什么对象上做什么”这样势必使得实现出来的系统使用上过于累赘，如果用户数量很多你可以想象必…
[/Quote]
多谢回复
功能权限×数据权限是很恐怖，现阶段的要求只是功能权限＋数据权限，两者不作交叉
对业务对象有那些操作，如增删改查，由功能权限去控制，最细粒度为业务，不是数据，这里不作讨论，已经有很成熟的方案
这里只是讨论对可操作的业务数据范围的控制，也就是单纯的数据权限
打个比方，很多人吃蛋糕，谁用什么工具，是干瞪眼看、可以切还是可以挖的问题解决了
现在要解决谁可以吃多少的问题
首先定义一个吃的规则，比如小孩可以吃带奶油的部分，女人可以吃底下蛋糕部分..
然后所有人按照这个规则各取所需，不用管蛋糕的品种、大小、数量，再拉一车来，照样吃之
小孩、女人可以认为是操作主体类型
蛋糕可以认为是业务类型
吃的规则就是数据权限
啰嗦半天，不知讲清楚了没有:-)

SINCE1978 2009-05-14

打赏
举报

上述数据权限可以用aop来解决，功能权限用j2ee 的 filter

pathuang68 2009-05-13

打赏
举报

权限管理，看似简单，实则复杂之极...

jinxfei 2009-05-13

打赏
举报

[Quote=引用 14 楼 Little_qd 的回复:]
抛砖
现在只是有想法，还不清晰，不知可行否
★功能权限解决who what问题，数据权限解决who where what问题
★利用组织结构可以天然的实现上下级隶属关系类的数据权限控制
★业务类的数据权限
1、what：定义业务对象的类型，作为数据权限的目标，比如销售纪录是一种业务对象
2、where：定义业务范围，作为数据权限的场景，比如区域是一种场景类型
3、who：定义主体，作为数据权限的使用者，比如操作员是一种主体
主体、场…
[/Quote]

what,where这两个词很有歧义，还不如直接用中文。

功能权，解决谁能够做什么的问题。
数据权，解决谁能够在什么对象上做什么的问题。

功能和数据，我们都可以认为是一种权利（privilege)，

who，也就是用户，如果要想灵活，应该至少抽象成：
用户、角色、组
三种定义。

用户可以属于多个组、多个角色，

功能权，通常可以分配到用户、角色，
数据权，通常可以分配到用户、组。

组和用户的部门结构进行映射。

但我还是要重申我的观点：
权限管理是一个涉及全局的事情，不宜做得过于复杂，不宜融入太多的业务逻辑、不宜管理过于细致的数据（量大会极大增加系统性能负担）。

比如，你说的例子中，
销售记录，是每天都在动态变化的，我总觉得，不适合纳入权限管理。
而2000元以上的记录，我觉得这是一个业务概念，更不应该体现在权限管理中。

换一个角度想，无论销售记录如何变化，统计报表相对稳定，
我觉得报表可以作为一种数据进行授权管理，
比如：A领导可以查看所有报表，而B领导，只可以查看2000元以上的报表。
这只需要给领导分配不同的报表就可以了。

jurenwangzi8 2009-05-13

打赏
举报

谢谢分享!

加载更多回复（29）

讨论数据权限

相关推荐