Is your feature request related to a problem? Please describe.
目前openapi的权限校验器ConsumerPermissionValidator和portal的权限校验器PermissionValidator,两者拥有的方法是比较高度一致的,

差别主要体现在入参不一致,ConsumerPermissionValidator需要获取HttpServletRequest对象来获取ConsumerId。
我认为这边完全可以去除掉这个入参,理由有两个:
- 这个入参使权限校验器与Http强绑定了,不方便进行后续更换网络层协议的扩展。
- 完全可以使用 RequestContextHolder 来获取当前线程绑定的 HttpServletRequest 对象,性能开销上并不会带来特别大的影响。
这样就可以使两边权限校验器的api对齐,并且权限校验器应该只和业务逻辑相关。
Describe the solution you'd like
创建一个接口 IPermissionValidator,包含这些校验方法,两边的权限校验器分别实现。
portal实现的权限校验api是多于openapi的,这时对于openapi还没实现或还没用到的校验方法,可以暂时直接返回false。
Describe alternatives you've considered
None
Additional context
None
Is your feature request related to a problem? Please describe.
目前openapi的权限校验器ConsumerPermissionValidator和portal的权限校验器PermissionValidator,两者拥有的方法是比较高度一致的,
差别主要体现在入参不一致,ConsumerPermissionValidator需要获取HttpServletRequest对象来获取ConsumerId。
我认为这边完全可以去除掉这个入参,理由有两个:
这样就可以使两边权限校验器的api对齐,并且权限校验器应该只和业务逻辑相关。
Describe the solution you'd like
创建一个接口 IPermissionValidator,包含这些校验方法,两边的权限校验器分别实现。
portal实现的权限校验api是多于openapi的,这时对于openapi还没实现或还没用到的校验方法,可以暂时直接返回false。
Describe alternatives you've considered
None
Additional context
None