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

说白了，在按钮层面设计一套精准的菜单权限功能，其实很简单。
核心在于用户、角色和菜单之间的三维关系。
我们先来说说最重要的事情。
用户和角色之间是多对多的关系，角色和菜单之间是多对多的关系。
用户通过角色与菜单相关联。
我们去年做的项目中，用户角色关联表包含了3 000级左右的数据。

还有一点，菜单表的设计是关键。
菜单表采用树形结构，关键字段包括parent_id、level、path等。
例如，当我们设计一个名为menu_auth_db的数据库时，菜单授权模块的数据库设计通常是用5 张表完成的。
这里有一个关键细节。
Path字段的存在旨在解决前端树组件在选择子集时无法传递父节点ID的问题。

一开始我以为这个字段是多余的，后来发现是错误的。
这在某些场景下是必要的。
等等，还有别的事。
后端做权限检查的时候，主要是为了防止未授权的用户发出接口查询请求。
例如，我们可以使用菜单编码来判断用户是否有权限请求该界面。

很多人都没有注意到这一点。
要实现权限控制，后端只需要编写权限注解和代理拦截器即可。
比如我们添加@CheckPermissions注解，并填写相应的菜单代码。
这样当你想要控制某个接口的权限时，只需要添加这个注解即可。

最后，我想提醒您一个容易陷入的陷阱。
实际操作中，应注意path字段的合理使用以及授权注解的正确配置。
我认为根据实际业务需求灵活运用这些设计思想和技术是值得尝试的。

给女朋友讲某宝是如何设计用户权限管理的(一)

哈，我只是回应这个问题！上周有客服经理天天骂我们，说他们的系统用了spring security，乱七八糟，改权限需要把整个系统锁起来测试。
您认为这可能是一个问题吗？
关于你说的那些表 Apache Shiro 和 Spring Security 真的很棒。
2 02 2 年我在深圳一家大工厂做项目的时候，早期就使用了Spring Security。
但后来我们发现了一个洞。
有一次，Shiro的过滤链的配置稍有改动，整个系统就崩溃了，日志也看不懂。
最后通过查看源码发现了问题所在。
你觉得好还是不好？ （停顿）Sa-Token确实不错，文档也清晰，但我经验很少，不敢乱推荐。

为什么应该开发自己的权限框架？ 你所说的关于这件事。
框架很舒服，但正如你所说，它是一个“黑匣子”。
例如，2 02 1 年我在杭州带领团队做一个小程序时，有一个需求“有些部门就是看不到他们项目的报告”。
因此，True Security 的许可证配置比程序更复杂。
最后，我们干脆注销了自己。
尽管构建设备花了一周的时间，但随后的许可证更改比更改弹簧配置快了一百万倍。
关键是要知道每一行代码的作用。

你的设计想法很有趣 特别是凭证类认证和AOP的概念相当清晰。
我将向您添加一些内容：
1 Credential Type：建议多添加一些状态字段（比如是否禁用），否则用户突然无法登录时会比较麻烦。
2 .动态能力：可以添加“权限生效时间”字段。
这是2 02 3 年上海的物流系统。
但是，一些权限必须每天更改。
3 .Thochen的管理：必须增加呼气机制。
我在之前的项目中没有添加它，但它使用了某种符号作为密钥，并且在数据部分的末尾
摘要泄露了。
列出的类别很全面，所以我将添加一些； 权限规则引擎：例如使用Easy规则引擎。
如果以后想改变权限逻辑（比如工作岗位的部分），可以直接调整配置规则，无需修改代码。

日志组件：应记录每次身份验证失败。
我在2 02 2 年接手了旧系统，因为没有日志。
最后，我发现有人使用日志记录来窃取帐户数据。

最后他们打扰了一些事情。
你对你的画有大概的了解了吗？兄弟你别画那么多啊！建议先写最简单的版本； 1 、首先实现用户名密码登录+固定资源权限 2 .添加动态能力（比如使用注解控制权限的方式） 3 、他们最后偏向token管理（他们只是用Redis来保存）
你想想，2 02 3 年我带新人做许可系统的时候，我是一步一步做的，上线一个月后没有出现什么大问题。
现在回想起来，避免“系统重启修改权限”的陷阱是非常重要的。
对了，你没有说如何使用AOP实现系统认证……这个需要详细讨论。
无论如何，你应该尝试第一个版本。
如果还不行就回来问我！