权限设计-系统登录用户权限设计

需求分析—场景

假设需要为公司设计一个人员管理系统,并为各级领导及全体员工分配系统登录账号。有如下几个要求:
1.  权限等级不同: 公司领导登录后可查看所有员工信息,部门领导登录后只可查看本部门员工的信息,员工登录后只可查看自己的信息;
2. 访问权限不同:如公司领导登录后,可查看员工薪水分布界面,而员工则不能看到;
3. 操作权限不同:如系统管理员可以在信息发布界面进行增删改查发布信息,而普通员工只可以在信息发布界面进行查看,不能修改、删除和新增。

功能分析

1. 登录一个系统,基本都需要用户输入用户名、密码;
2. 每个用户的 角色不同,则其 访问权限一般也不同, 如:
       系统管理员:可以查看所有界面;
       普通用户:只能查看部分界面。
3. 不同的用户,即使可以查看同样的界面,但在该界面上可进行的 操作权限也不同,如:
       用户1:可以在界面1上进行增删改查;
       用户2:只可以在界面1上查看,不具备增删改功能;
4. 不同用户基本都对应不同角色,如:用户1、用户2分别对应管理员角色、操作员角色,角色之间也存在 权限等级的差异,如:
      角色1:对应省级管理员;==>可以查看该省下的所有学校信息;
      角色2:对应市级管理员; ==>可以查看该市下的所有学校信息;
      角色3:对应县级管理员; ==>可以查看该县下的所有学校信息;
不管是省、市、县哪个系统管理员,他们可访问的界面都是相同的(即访问权限相同),且在每个界面上可进行的操作权限也相同的,不同的是每个管理员角色可以访问的学校个数和学校范围不同,这里称这种不同为:权限等级不同;

总结:
从上面的分析中,主要涉及到以下几个概念:
1.角色:
       如系统管理员角色,系统操作员角色,普通用户角色;
       不同的角色,其访问权限是不同的,即可访问的模块(界面)集合是不同的;
       角色的权限等级也不同,权限等级如:公司领导、部分领导、普通员工;
2. 模块:(界面)
    模块就是指具体的界面,每个模块上又有不同的操作,如增删改查;
3. 访问权限:确定角色可以访问的模块(界面)集合;
4. 操作权限:确定可以在各模块(界面)上进行的操作集合,如增删改查;
5. 权限等级:即确定角色可以访问的范围,如:
         角色1:权限等级为 公司领导,则 可以查看公司所有员工信息;
         角色2:权限等级为部门领导,则只可以查看该部门所有员工信息。


数据库设计

总体模型:




1.模块定义表:
模块是分层级的,如:信息管理–>联系方式管理;

每个模块都有上级模块。

2. 角色定义表:
含有角色权限等级,用于为角色分配权限等级;
角色权限等级:是一个菜单选项,包括公司领导、部门领导、普通员工;

3.授权定义表:
用于给角色分配访问权限以及为每个模块分配操作权限;
1个角色可以含有多个模块,同样1个模块可以分配给多个角色,所以角色和模块是多对多的关系;这种多对多的关系可以使用关系表来实现,即通过联合主键和实现关系表:

表中含有字段“操作权限”,用于给每个界面分配操作权限,见下图:
若该模块有增删改查功能,则操作权限15,即二进制的“1111”,若该模块只有查看功能,则操作权限为2,即二进制的“0010”,同样的,“0111”表示该模块有增、改、查功能;

4. 系统用户表:

该表中“角色权限等级”—>应与“所属角色”中的权限等级保持一致,之所以该表中重复该字段,是为了方便查询。
角色权限等级取值:
  1. 公司领导:company_id不能为空;
  2. 部门领导: company_id、dept_id不能为空;
  3. 普通员工: company_id、dept_id、staff_id不能为空;



登录执行过程

1. 系统登录时,首先输入用户名、密码;
2. 确定 访问权限
   2.1 判断该用户的“角色编号”;
   2.2 在“授权定义表”中根据该“角色编号”查找相应的模块,找到的模块集合即是访问权限;
3. 确定 操作权限
   3.1 在2.2步骤中查询到的每个模块都有相应的操作权限,即构成了每个模块的操作权限;
4. 确定权限等级
   4.1 结合该用户的“角色权限等级”+“公司标识”+“部门标识”+“员工标识”,到员工信息表中去查找相应员工,具体如下:
    角色权限等级 取值:
   1. 公司领导:查找< 员工信息表.公司 标识==该用户.公司标识>的所有用户
   2. 部门领导: 查找< 员工信息表.公司 标识==该用户.公司标识 && 
                                  员工信息表.部门 标识==该用户.部门标识 >的所有用户
   3. 普通员工: 查找< 员工信息表.公司 标识==该用户.公司标识 && 
                                  员工信息表.部门 标识==该用户.部门标识 && 
                                  员工信息表.员工 标识== 该用户.公司标识 >的所有用户
   

  • 26
    点赞
  • 173
    收藏
    觉得还不错? 一键收藏
  • 13
    评论
课程简介:历经半个多月的时间,Debug亲自撸的 “企业员工角色权限管理平台” 终于完成了。正如字面意思,本课程讲解的是一个真正意义上的、企业级的项目实战,主要介绍了企业级应用系统中后端应用权限的管理,其中主要涵盖了六大核心业务模块、十几张数据库表。 其中的核心业务模块主要包括用户模块、部门模块、岗位模块、角色模块、菜单模块和系统日志模块;与此同时,Debug还亲自撸了额外的附属模块,包括字典管理模块、商品分类模块以及考勤管理模块等等,主要是为了更好地巩固相应的技术栈以及企业应用系统业务模块的开发流程! 核心技术栈列表: 值得介绍的是,本课程在技术栈层面涵盖了前端和后端的大部分常用技术,包括Spring Boot、Spring MVC、Mybatis、Mybatis-Plus、Shiro(身份认证与资源授权跟会话等等)、Spring AOP、防止XSS攻击、防止SQL注入攻击、过滤器Filter、验证码Kaptcha、热部署插件Devtools、POI、Vue、LayUI、ElementUI、JQuery、HTML、Bootstrap、Freemarker、一键打包部署运行工具Wagon等等,如下图所示: 课程内容与收益: 总的来说,本课程是一门具有很强实践性质的“项目实战”课程,即“企业应用员工角色权限管理平台”,主要介绍了当前企业级应用系统中员工、部门、岗位、角色、权限、菜单以及其他实体模块的管理;其中,还重点讲解了如何基于Shiro的资源授权实现员工-角色-操作权限、员工-角色-数据权限的管理;在课程的最后,还介绍了如何实现一键打包上传部署运行项目等等。如下图所示为本权限管理平台的数据库设计图: 以下为项目整体的运行效果截图: 值得一提的是,在本课程中,Debug也向各位小伙伴介绍了如何在企业级应用系统业务模块的开发中,前端到后端再到数据库,最后再到服务器的上线部署运行等流程,如下图所示:
文件系统数据权限设计是指在文件系统中设置不同用户或用户组对不同文件或目录的访问权限,以保护文件的安全性和完整性。以下是一些设计数据权限的建议: 1. 确定用户和用户组:在开始设计权限之前,您需要确定哪些用户和用户组将访问文件和目录。例如,您可能需要为管理员、普通用户和匿名用户创建不同的组。 2. 确定权限级别:一旦您确定了哪些用户和组将访问文件和目录,您需要确定每个级别的权限。通常,文件系统权限可以分为读、写和执行。只有管理员组可以更改系统级别的权限。 3. 限制权限:您应该尽可能限制用户的访问权限,以确保文件和目录的安全性。例如,您可以将文件夹权限设置为只读,而只有某些用户或用户组可以更改或删除文件。 4. 定期审查权限:为了确保文件系统安全,您应该定期审查文件和目录的权限。如果某个用户或用户组不再需要访问某个文件或目录,您应该撤销他们的权限。 5. 使用ACL:Access Control Lists (ACLs) 是一种高级权限机制,它允许更细粒度的权限控制。使用ACL可以允许或禁止对某个用户或用户组的某些特定操作,而不是简单的读、写和执行权限。 6. 确保用户身份验证:最后,您应该确保所有用户都需要身份验证才能访问文件系统。这可以通过设置密码或使用其他身份验证机制来实现。 综上所述,文件系统数据权限设计是一项重要的任务,可以帮助保护敏感数据并确保数据安全。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 13
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值