一次AOP与面向接口之间徘徊的选择

一。背景：

一个基于spring的web系统已经正常运行了几年。安全部门扫描，发现存在弱密码漏洞，要求修复。

二。初步分析：

用户很多使用的是初始密码，修改密码了的也是几个数字居多，确实存在密码安全问题。但是系统已经上线运行，用户也不是每天都会登陆，长的可能存在1-2周再使用系统。要尽快发布，堵住安全漏洞，就要考虑尽快解决，同时还能平滑过渡。从复用度来讲，还要尽量能够被其他项目复用。也要考虑未来新增用户的时候，给用户的初始密码能否有效的要求用户修改。

三。初步设计

1.快速堵住安全漏洞

用户每次登录就校验密码强度，当前密码强度不满足就拒绝登录验证。

2.本次修改怎么才能平滑过渡

因为密码强度不满足要求的都拒绝登录验证了，登录页提供一个用户修改密码的链接。密码修改界面既要验证当前密码，也要验证新密码是否符合强度要求。系统登陆后，内部还有密码修改的功能，还是要验证新密码的强度。

3.实现功能复用

新开发未登录密码修改界面。

可以使用AOP做登录验证的前置切面，对密码强度进行验证。

也可以修改原来的登录验证逻辑，在登录验证之前调用密码强度验证。

密码强度验证已经算是基本的验证逻辑了，如果使用AOP在运维查找分析不是很快，基本逻辑就直接修改逻辑代码。但是不同的系统，可能有不同的密码强度要求，为了提升复用度，采用面向接口的方式设计。定义一个标准接口，里面有一个密码验证的方法。在密码验证逻辑部分，向spring请求实现该接口的所有实现，逐一调用验证。接口单独放一个jar包，作为标准接口。再建一个maven的jar工程，依赖验证标准接口jar，做一个基本的强度验证实现。如果有不做强度验证的系统，新发布后，因为没有验证实现，在向spring请求实现没有拿到，就不会验证。如果有不同验证需求的系统，可以依赖标准验证接口，实现自己的密码强度验证实现，工程就依赖自己的验证实现即可。最大程度的实现了对历史已经上线不验证的系统和未来不同验证强度要求的系统兼容，实现了最大的复用度。

4.新增用户的初始密码修改

目前，新用户的注册不是用户自助注册，采用的是管理员注册的方式。注册后会给用户发送初始密码，要求用户修改密码。

更新后，用户如何不修改初始密码（简单数字），无法登录。基本流程不变的情况下，用户密码修改初始密码才能登录了，提升了系统安全性。