想跟您请教关于COO的问题

天朝红雨 发布于 2017/12/05 15:28
阅读 61
收藏 0

@Jnoee 您好,想跟你请教个问题:您的COO框架中整体感觉非常先进,大幅提高了开发效率也保证了项目的稳定性。但有几处个人感觉有点不妥的地方,不知道是不是我没有用对:

1.是BeanUtils类中对于属性的获取和赋值是直接采用的属性而非其set/get方法。

2.shiro授权验证的实现是在coo框架内部的LoginRealm通过用户名+密码方式实现验证,这种方式制约了其拓展性,比如要实现手机+短信登录,或者微信授权登录等,目前应该是比较棘手...我觉得密码验证等操作应该在AbstractSecurityService中提供默认实现,由SecurityService验证完成后再调用shiro使用id去注册权限框架至于LoginRealm则无需验证密码,因为只要被shiro调用则必定可以认为是已通过验证的.(用id而非用户名注册权限框架的原因是因为假设用户通过微信注册那么用户名通常应该为null,如果提供username那就尴尬了),

3.框架内部对于freemarker进行封装的宏存在XSS漏洞,可以被用户提交的特殊字符串注入js脚本.

以上,还望老师多多指教.

加载中
0
Jnoee
Jnoee

好久没有上来了,关于几个问题我是这么想的:

1. BeanUtils类用的java反射机制来实现,参考过commons和spring中的相关类,没有基于get和set方法是考虑灵活性。因为我有时会用它操作一些第三方包的类,这些类可能不提供get和set方法,这是双刃剑,用的时候是需要小心。

2. 这一块的封装是基于我以往项目的常见场景,我大多做的都是后台管理系统。UI框架选型DWZ也是因为如此,适合做后台管理系统的快速开发。你说的几种情况可以扩展或覆盖已有的组件来实现,User、Organ、Actor、Role都是基于最简属性构建的基类,到实际应用是需要扩展属性的。登录方法以及相关组件都是基于spring的组件注入的,你可以修改、覆盖甚至直接用新的组件替代。

3. 关于XSS注入问题,我个人觉得不是在封装宏这个层面来解决的。

近半年时间因为工作没用到的关系,没有对coo进行持续的改进。coo会改造成基于spring boot的,可以应用到spring cloud微服务架构中去。另外,UI这块备受争议,我考虑做成前后端分离,不再集成UI框架,只提供API接口。coo是个人积累的应用框架,基本上都是我自己带队的产品和项目才会使用。你最好不要直接使用,可以将里面一些你觉得好的机制或组件移植到你自己的框架中去。

返回顶部
顶部