软件设计权限-功能原子性

最近负责一个项目的重构架构实施,执行到权限这一块时,发现对原有的权限体系很难下手,包括对表间设计或者是说对权限的显示控制。


权限,无非就是赋权和权限拦截。


先从权限拦截开始说起吧,对于普通的web来说,对权限的拦截无非就是前端加一个fiter类似的拦截器,对用户访问的权限进行拦截。比如说,用户采用产品码和功能码进行访问,比说用户这个大的产品下有用户创建这样一个功能。但是用户创建又分为1.填写表单 2.详细信息录入 3.提交创建成功 。在这里如果说用户这个大产品下,对创建这样的功能则需要具有原子性,及如果创建用户是2001 200101这样的产品码和功能吗,则200101要包含三个部分,填写表单,详细信息录入,提交创建成功。 即再拦截的时候,如果没有功能权限,则都不能访问。

之所以提出这一点,就是因为现在的系统缺失了这种功能原子性。还是上面的例子,分为3个功能码,200101作为填写表单 200102作为信息录入 200103作为创建。在这种情况下会出现一些很严重的问题,比如说拦截的时候,需要对这三个功能码都进行拦截。


接下来讨论赋权。

赋权就是上级对下级的赋权,其中包括上级用户对下级用户的赋权,上级组织对下级组织的赋权。

通常来说,权限体系会有如下的表设计:


T_ROLE :可以动态的定义系统中的

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值