一、该问题的重现步骤是什么？
1. 新建一个角色后，给这个角色分配菜单。该角色对应的用户登录后，只能访问分配的菜单，但是能访问分配菜单之外的接口。
2. 因为我没做接口权限。想问下这个框架的接口权限为什么不是跟着菜单绑定呢？而是要手动建接口权限，手动分配。
3.这样不合理：1.接口是属于后端的，后端的内容不能直接面对用户；2.用户分配菜单，无法理解什么是接口权限，也根本不知道分配了这些菜单，对应了哪些接口权限。
4.之前项目都是接口权限跟着菜单绑定，用户只要分配菜单就行，对应角色的用户无法访问分配菜单之外的接口。
5.目前找不到Bladex框架接口权限的最佳使用方式，主要就是这个框架的接口权限不跟着菜单走，挺接受不了的。
二、你期待的结果是什么？实际看到的又是什么？
期待接口权限和菜单绑定，只要分配角色菜单就行。实际分配了菜单权限，还得分配接口权限。
三、你正在使用的是什么产品，什么版本？在什么操作系统上？
Bladex-Boot,4.1.0,windows,linux
四、请提供详细的错误堆栈信息，这很重要。
五、若有更多详细信息，请在下面提供。
这是前后端分离的系统，不是前后端揉杂在一起的系统。如果前后端不分离，页面是先通过后端渲染才会调用接口，配置菜单后，渲染的页面无法访问自然不用去关注页面里接口的问题。如果前后端分离，那么后端是无法去管控页面的加载与接口的调用的。
比如前后端分离的系统，前端有一个模块的路由地址是 /notice/blog ，后端对应的接口是 /blade-desk/notice/list 。
那系统如何知道他们之间的关系？配置了/notice/desk的菜单权限后，系统如何知道要对 /blade-desk/notice/list 、 /blade-desk/notice/save、 /blade-desk/notice/xxx 的接口进行控制。
如果你有好的全自动适配的解决方案可以反馈一下，我们评估是否可以进行开发。
menu表增加一个perm的字段，每个菜单对应一个权限code，接口上面写明权限code，有这个权限code才能访问这个接口，这样接口就和菜单绑定了。分配了菜单后，这些角色就有这些菜单对应的权限code,就只能访问这些权限code对应的接口，自然不能访问其他菜单对应的权限code的接口。
这不还是要手动配置吗，没法全自动啊。每写一个接口就要配置一个注解。而且后续如果不需要了，还要去改源码再编译。你说的这个方案bladex一直都有，除此之外bladex还支持在线动态配置，什么时候要什么时候不要，在线修改就能生效，不需要去重启服务。
是的，以前就是这样做的，没写一个接口，就在上面写上对应菜单的权限code。但是至少不用手动分配接口权限，而且实现了权限是跟着分配的菜单走的。
但是Bladex框架目前没有将接口权限和菜单绑定，没法实现接口权限跟着菜单走。让用户手动去像分配菜单权限一样去手动分配接口权限，这个没法接受。因为接口不像菜单一样，用户可以理解，而且接口很多，也记不住这些分配的菜单对应了哪些接口。
期待的就是不要有分配接口的这个操作，只要分配菜单就可以，这样用户才能接受。而且分配了菜单后，只能访问这些菜单涉及到的接口，其他菜单的接口无法访问。
但是目前感觉得手动去绑定菜单和接口的对应关系。如果框架能自动带了这个功能，就好了。
bladex给出的方案绝对比你说的十年前的方案更方便。他支持全局匹配，根本不需要去记每个接口地址，也不需要因为业务变更而重新修改代码再重新部署。
还有一个，复杂点的系统，是不可能只有菜单权限的接口的，除了菜单权限的接口以外还有很多对接第三方或者开放API的接口。这些都是底层功能接口，和菜单无关，他们要配置权限自然是需要单独一个模块来配置的。
如果都放在菜单里，那么耦合就非常严重了，所以接口权限这个功能肯定是需要的。不能因为一个菜单绑定看似方便就否定接口权限这个大模块的存在意义。
其实你说的这个方案也是大部分系统在用的，但是他也有很大的局限性，他不能免重启生效，他有需求变动要去修改源码再部署。所以单独起来在线配置的接口权限是泛用性更强的。
至于你要求的这个功能，如果后续其他用户也需要，我们会考虑单独开一个小功能去支持，只是他有局限性，优先级不高，不保证开发。
扫一扫访问 Blade技术社区 移动端
加载中...
苏公网安备 32041102000998号