请教权限设计

[leon51]

有一段时间没有来论坛发贴了。

有一个小的软件，我原来按人员的组别来控制菜单访问、数据操作等权限，感觉不是很好。
于是在网上参考了下别人的设计，但是动辄5、6个表，感觉又大复杂了，似乎完全没有必要搞得那么复杂(大家经常借别人的帐号)
请教如何设计一个稍简单的轻量级的权限管理呢？

[全栈极简]

用户、角色、菜单、用户-角色、角色-菜单、用户组、用户-用户组、用户组-角色，这个结构应该很清晰呀。

[泳装魔王]

记得springsecurity就可以很方便的做权限管理

[以专业开发人员为伍]

假如说数据是一个巨大的垃圾场，那么你把这个垃圾场里边的每一“个”垃圾都分权限、而且要预测到将来所有可能的操作，这其实是不可能的。所谓权限设计其实是偷懒的做法，是对静态数据设置所谓的动态权限。 这个做法的前提是非常入门级的习惯，就是我们都从打开一个数据库系统的客户端管理工具入手去学习数据库的 DDL、DML 等等编程语句，我们打开一个简单的“左边是数据库对象表格树，右边是 DataGrid 编辑”的界面，然后千篇一律地查询和修改表格。换句话说，诺大一个用户企业，初学者也就学会了给几个数据库操作员设计程序界面的那种思路。根本没有学过信息系统设计思路。 真正的信息系统要什么权限？组织架构本身就是跟各种业务表单相结合的。比如说一个负责a地区的业务员提交的业务日报、发票等等，那么按照流程就会被后续的7、8个环节所审核和约束。假设他要订阅部门业绩分析报告，那么这个报告系统预先就设计为仅仅根据订阅者所在的地区而进行统计。 也就是说，走流程的业务系统，在每一个业务表单（包括报表下载表单）上就嵌入了最终数据权限，而且这种嵌入是无限深度地直接硬编码的。业务表单是千变万化的，所以其实不值得空洞地忽悠什么许多个表的权限矩阵操作界面，谁用呢？

[以专业开发人员为伍]

有些忽悠人你的管理信息，所谓的“生成工具”，其实就是模拟数据库系统的客户端查询编辑工具（SQL Server的客户端管理器）的界面，千篇一律地弄一个各种数据库表的“增删改查”界面，顶多不过是允许2、3个关联表DataGrid联动编辑而已。这种软件做的很费力，于是这些人把这种软件开发思路当成宝贝，于是要给组织架构树上的各级人员设置数据查询和修改权限。 其实仅仅适合这种类似于模拟 SSMS 之类的数据库编辑工具的的软件。而不是实用的业务工作流软件。

[以专业开发人员为伍]

比如说一个业务代表每天提交日报，那么当他提交之后，系统就会按照工作流的配置信息，自动将下一步的工作提醒给他的组长、或者当地市场负责人，也就是相当于自动发邮件一样。那么接收人立即在手机或者电脑上收到任务提醒，告诉他每天还有什么事情要办。业务负责人可能打开一个、或者一批日报，审批、驳回，或者填写自己应该填写的各种评价和分析数据，然后系统根据评价和其他数据的内容而自动按照配置而选择下一步流转到不同的人.........获取报表也是如此，填写报表需求，然后提交之后，等待几秒钟或者几分钟之后收到投递回来的报表.........这种信息系统要什么数据权限矩阵？ 要清楚地知道：所谓权限设计是用来给数据库录入员用的，不是给业务系统用的。我们许多人都整天整年在开发初级的数据库增删改查 DataGrid 表格，而还没有摸索出真正快速、便捷地设计开发实用的业务前端。

[xuzuning]

既然是 大家经常借别人的帐号，那么你的权限系统就形同虚设，没必要存在了

[娃都会打酱油了]

RBAC，至少都是要好几个表的

[正怒月神]

角色权限，使用5-6个表，本来就不过分。 并且也是非常简单的了。

[大鱼>]

https://www.cnblogs.com/zkwarrior/p/5792947.html

[software_artisan]

引用 4 楼 sp1234 的回复:

比如说一个业务代表每天提交日报，那么当他提交之后，系统就会按照工作流的配置信息，自动将下一步的工作提醒给他的组长、或者当地市场负责人，也就是相当于自动发邮件一样。那么接收人立即在手机或者电脑上收到任务提醒，告诉他每天还有什么事情要办。业务负责人可能打开一个、或者一批日报，审批、驳回，或者填写自己应该填写的各种评价和分析数据，然后系统根据评价和其他数据的内容而自动按照配置而选择下一步流转到不同的人.........获取报表也是如此，填写报表需求，然后提交之后，等待几秒钟或者几分钟之后收到投递回来的报表.........这种信息系统要什么数据权限矩阵？ 要清楚地知道：所谓权限设计是用来给数据库录入员用的，不是给业务系统用的。我们许多人都整天整年在开发初级的数据库增删改查 DataGrid 表格，而还没有摸索出真正快速、便捷地设计开发实用的业务前端。

总有些数据是需要业务人员或管理人员录进系统的。。。

[SoulRed]

粒度不要太细，尽量有类似模板之类的设计。但还是需要结合项目实际情况。。。

[stevenjin]

如果需求简单，一个表能搞定。至于菜单的控制，也可以根据表中的用户名判断。

[leon51]

引用

既然是 大家经常借别人的帐号，那么你的权限系统就形同虚设，没必要存在了

我们领导的观念是提不提供是我的问题，怎么使用那是人家的问题

[leon51]

引用

如果需求简单，一个表能搞定。至于菜单的控制，也可以根据表中的用户名判断。

一个表能如何搞定？可否说得再详细点呢？谢谢

[zbdzjx]

一个很简单的方式： 1、用户表：账号、密码、姓名…… 2、菜单表：菜单ID、菜单名…… 3、用户-菜单表：账号、菜单ID、新增、修改、删除、打印…… 这种方式，在“用户-菜单表”中固定了就几种权限，如果要新增加一种权限，就要在“用户-菜单表”中增加一列。 只能用于界面少、权限项基本不变的小程序。 如果界面很多，增、改用户的权限，鼠标点起来能累死人的。