社区
分析与设计
帖子详情
关于角色数据权限相关问题,400奉上
极客诗人
2021-01-30 01:11:39
在我们实际业务中,权限是尤为重要的一个环节。
目前权限的解决方案也是有很多。
但最近在实际业务开发中,就有些问题如下:
1.管理角色默认拥有所有数据
2.在某些数据的
状态值
(例如流程节点XXX的)为指定时,某些角色能看见数据进行操作,操作后数据不可见。
望指点讨论,400奉上
...全文
3556
7
打赏
收藏
关于角色数据权限相关问题,400奉上
在我们实际业务中,权限是尤为重要的一个环节。 目前权限的解决方案也是有很多。 但最近在实际业务开发中,就有些问题如下: 1.管理角色默认拥有所有数据 2.在某些数据的状态值(例如流程节点XXX的)为指定时,某些角色能看见数据进行操作,操作后数据不可见。 望指点讨论,400奉上
复制链接
扫一扫
分享
举报
写回复
配置赞助广告
7 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
cn2719691
2021-02-04
打赏
举报
回复
有几个方式吧,第一种简单点,用户表记录权限,然后程序根据权限开放按键或显示之类的 另外高级点的就是再写个菜单表,与权限对应,或者直接与用户对应,运行时查询菜单表分别显示菜单。
以专业开发人员为伍
2021-01-30
打赏
举报
回复
引用 1 楼 极客诗人 的回复:
目前均是在代码中写死。 想将2更加灵活的处理,故此一贴,望赐教
这其实是某种业务架构、业务 API 的具体设计抽象层次不够的问题。是业务流程了解不深入的问题,是对业务不熟悉的问题,而不适合纠结“通用数据库表增删改查”概念。
以专业开发人员为伍
2021-01-30
打赏
举报
回复
例如一个系统如果有工作流图设计器,则在设计器上对工作流节点配置“业务流程权限”,来说明节点数据的产生来源(并不是产生数据权限本身,而是配置数据权限的生成规则,例如配置某节点只能被传送给流程发起人、当前节点的接收人所在部门的某个岗位的人,等等)。假设系统中还有一些资产,那么你需要配置资产保管负责人、资产复核负责人。假设系统还有一些研发代码和研发问题,你需要配置研发工作组,问题接收人、评估参与人、任务分配者、最底层干活的人、测试人员、负责上线的人、测试人员,等等。 一个不大的业务系统中假设慢慢产生有500种数据库表,那么你可能需要在10种不同的数据库表中为每一“行”数据指定你说的所谓的“某些角色能看见数据进行操作”这类东西。也就是说真正的系统在高级别的业务对象上控制权限,而不是在低级别的“通用数据”上控制权限。有些人假设系统开发最高级的事情就是弄个后台数据库的查询客户端 Table 来“增删改查”数据,这是最学究、最简单化、最 low的想法,看上去高大上,其实这跟刚工作3个月的学生灭有区别,远远脱离了业务系统架构。真正的系统是用 API 将所有客户端与后台数据库想分离,客户端根本不可能用一个所谓的数据库表增删改查 Table 界面来随便乱改数据。真正的系统能把百十来个 业务API 给开放给各个客户端系统且提高整个系统使用效率、使用价值就不错了,需要在 API 接口上分别控制“权限”,还纠结低级地“随便去增删改查所有数据”?
以专业开发人员为伍
2021-01-30
打赏
举报
回复
仅仅基于“数据层面”来设计权限,其实是最学究化、理想化的一种方式,这个前提是整个数据“读取”的 api 都被你自己编程控制情况下,例如你自己开发一个 SQLHelper且你自己解析、编译 sql 语句。 而基于工作流节点的权限管理,是基于“文档”的权限管理,是基于高一级别的“业务数据权限管理”。可见它不是基于 low 层面的通用数据库数据概念,而是基于业务领域分析来考虑。 进一步地可以看到,随着业务分析的深入,权限问题实际上在多“种”业务领域对象上都有涉及,而且其实是跟业务的“本质”相关的。例如工作流节点的权限,是在工作流图的设计器上进行配置,在工作流节点文档数据对象产生时指明了“发送人、接收人、抄送人”,这当然是与工作流协同、即时消息业务相关的。 可以说,认为“整个数据都能随便设置权限”其实是个幼稚的想法。更高级的想法反而是实际的——每一个业务服务模块的 API 各自判断的调用者是否有权限访问数据。先对业务领域进行详细设计,仅针对对某1、2种业务领域对象来适配权限系统,而不是以为纠结“所有数据”这种空洞的概念来适配权限概念。
圣殿骑士18
2021-01-30
打赏
举报
回复
写死不写死,也就是把配置存起来的问题,也不难吧
圣殿骑士18
2021-01-30
打赏
举报
回复
这不就是个数据过滤的问题吗,有难度?
极客诗人
2021-01-30
打赏
举报
回复
目前均是在代码中写死。 想将2更加灵活的处理,故此一贴,望赐教
相关推荐
再论
权限
和用户
最近,
奉
上名。做个
权限
和用户模块。我的思路是菜单和操作
权限
分开。菜单和用户关联,用户和
角色
关联。
角色
是
权限
的集合。
权限
项是到具体的页面。菜单和
角色
有部分的重合的意思。上边的意思是
权限
添加时,有菜单项。
权限
赋予
角色
。
角色
赋予用户。在判断
权限
的同时,就判断菜单的使用情况。我的想法是,菜单是操作
权限
,页面也是
数据
权限
的。上边的理解是
数据
和操作是统一的。现在是按上边的思路在弄呢。各位有好的思路可以告诉我的...
利用Mybatis拦截器实现
数据
权限
个人博客纯净版 利用Mybatis拦截器实现
数据
权限
在我们日常开发过程中,通常会涉及到
数据
权限
问题
,下面以我们常见的一种场景举例: 一个公司有很多部门,每个人所处的部门和
角色
也不同,所以
数据
权限
也可能不同,比如超级管理员可以查看某张 表的素有信息,部门领导可以查看该部门下的
相关
信息,部门普通人员只可以查看个人
相关
信息,而且由于
角色
的 不同,各个
角色
所能查看到的
数据
库字段也可能不相同,那么此处就涉及到了
数据
权限
相关
的
问题
。那么我们该如 何处理
数据
权限
相关
的
问题
呢?我们提供一种通过Mybat.
impdp
权限
oracle,data pump expdp/impdp丢失
权限
角色
grant role的
问题
对于使用data pump的
数据
迁移,expdp/impdp可能存在丢失
权限
角色
grant role的
问题
对于此类
问题
, 可以考虑使用 下面的expdp/impdp脚本仅仅导出希望导出的用户的
权限
和
相关
角色
JOB_NAME=EXPDP_USERSDIRECTORY=DTPUMPFULL=YDUMPFILE=users_privs.dmpLOGFILE=users_expdp.logINCLU...
用户
权限
管理之RBAC
1.RBAC简介 RBAC(Role-Based Access Control,基于
角色
的访问控制),就是用户通过
角色
与
权限
进行关联。简单地说,一个用户拥有若干
角色
,每一个
角色
拥有若干
权限
。这样,就构造成“用户-
角色
-
权限
”的授权模型。在这种模型中,用户与
角色
之间,
角色
与
权限
之间,一般者是多对多的关系。 2.先
奉
上RBAC的一张简易流程图 可以看出
角色
表起到了一个承接的作用 把
权限
下发给每一个
角色
,而用户可以选择
角色
来间接的获取
权限
3.RBAC的优点缺点和我理解的RBAC 3.1RBAC的优缺点 先说说
发帖
分析与设计
分析与设计
.NET技术 分析与设计
复制链接
扫一扫
1.3w+
社区成员
5771
社区内容
.NET技术 分析与设计
社区管理员
加入社区
获取链接或二维码
帖子事件
创建了帖子
2021-01-30 01:11
社区公告
暂无公告