手把手教你搞定菜单权限设计，精确到按钮级别

设计菜单权限时；用户首先看角色和菜单关系。
用户和角色是多对多，角色和菜单是多对多。
通过角色的用户上下文菜单。
某些系统具有可扩展的直接用户上下文菜单。

菜单表设计，树形结构。
创建数据库 menu_auth_db 并填充 5 个表。
关键字段是parent_id；级别和路线。

使用 Springboot+mybatisPlus 快速构建。
添加新菜单，parent_id；级别 关注流量。
初始化7 个数据并显示菜单。

path字段的作用：选择子集时，前端树元素不传递父ID；后端使用该路由来存储主路由。

后端授权控制：防止未经授权的用户请求。
使用菜单代码来确定权限。
编写权限注解和代理拦截器，并在接口中添加@CheckPermissions注解。

用户张三，启动角色visitor并设置菜单权限。
查询张三的菜单权限，查看角色查询权限。

提供了获取项目源代码的方法。
欢迎提出意见和投诉。

谁能说说权限是如何设计的?

坦率地说，在许可设计方面没有一刀切的解决方案。
当我考虑 Windows 权限时，我认为它确实被分解为角色。
如果您考虑一下，如果权限可以像控制文件中的某一行一样精细，那会很方便，但您可能会疯狂地使用它 - 这显然是过度设计的。

有趣的是，给软件添加权限控制是一项基本功。
尤其是在处理数据库的时候，如果没有这个功能，几乎无法使用。
通常的做法是让注册用户查看各个功能菜单，清楚地看到谁拥有什么权限。
但问题是现在的软件非常强调易用性。
一个功能可以有多种打开方式——工具栏、右键菜单等，甚至可以在不同的地方使用。
如果权限控制仍然坚持只能查看主菜单，用户肯定不会乐意使用。

那么现在流行的是基于角色的设计，用户角色权限等，具体操作是先检查用户属于哪个角色，然后检查这个角色有什么权限，最后判断用户是否可以这样做。
关于数据库，可以看这个博客，这个博客很实用：http://www.cnblogs.com/wuhuacong/archive/2 009 /06 /1 9 /1 5 07 06 5
但说实话，这个方法用得太多有时会很烦人。
例如，有时某个角色的权限设置得太宽泛，结果用户可能会无意中做很多不该做的事情，这有点复杂。
但在设计、平衡安全性和易用性方面总是需要权衡。
归根结底，还是要看具体场景。
我自己还没有运行过这个。
我错过了有关X的数据，但我建议你验证一下。

如何设置数据库的权限

嘿，兄弟，我记得前年我在那家公司设置数据库权限时真的很困惑。
起初，必须弄清楚每个用户的身份和角色是非常乏味的。
我们公司有几十个用户，每个用户都有不同的权限。
例如，有的人负责数据查询，有的人负责数据修改。

首先，我登录数据库管理界面，创建一个新的用户帐户，并输入用户名和密码。
这很容易。
关键是“权限管理”部分，必须对每个权限项进行一项一项的检查，极其麻烦。
那时，您必须配置可以查看哪些数据、可以更改哪些数据以及可以删除哪些数据。
感觉就像我在玩一个猜谜游戏。

一旦我设置了只读用户权限，但那家伙仍然可以更改数据，这真是令人困惑。
后来我意识到我没有仔细查看具体的权限设置，并认为只读意味着我根本无法更改它们。
结果，无法添加新数据。
这提醒了我在设置权限时要小心谨慎。

还有一次，我们公司想要迁移其数据库。
那段时间我每天都和数据库打交道，手都快断了。
您需要确保迁移后每个用户的权限保持不变，这可能是一项艰巨的任务。
最终我参考了官方文档，一步步按照，成功完成了。

所以，兄弟，设置权限的时候要小心，多看官方文档或者寻求专家帮助。
不要像我一样，只有出了问题才后悔。
这需要极大的细心和耐心。