记录一个耗时半年的defect fix过程

某一天，邮箱里出现了个新defect，报告说我负责的产品有个安全问题：产品的api url允许别人输入无数次密码，这会易于遭受password brute force攻击。

打开defect，看过具体过程，我打开测试环境，试了一下其他几个相关产品的类似的URL，发现有相同的问题。那么基本可以判断是个common issue。加上调查说明，我将defect重新转给了相关的同事。

不料，几个月后，我发现这个defect重新出现在我的邮箱，仔细一看，描述类似，号码却跟之前不同。打开原来的defect，发现它声称被fixed了，可是问题依然在我这边重现。我重新做了上次的调查，ok，问题还跟以前一样，不仅仅出现在我负责的产品这里。我基本可以肯定，对方并没有真正的fix这个问题。我写email去问对方都做了哪些修复，他期待他的修复后，系统应该呈现什么样的现象。对方语焉不详，只是提到他期待401，我的经理建议我做个深入的调查。

于是，我预定了一个测试环境，打开WebSphere Application Server（WAS）控制台，打开trace，开始调查。

根据url的特征，我找到了相应的处理代码。研读代码后，我确认跟我的代码没有关系。

然后研究web.xml，想确认一下访问这个url的时候，filterchain如何，都有哪些filter处理了这个请求。不过查看过相关的代码，并结合trace log，发现并没有可疑对象。

这时候，我基本可以肯定我绝对可以踢回这个defect了，但是好奇心驱使我进一步去找到原因。于是，我下载了一些我认为可能处理相关信息的project代码，输入某些关键字进行搜索，果然找到了一些相关配置文件，再然后，根据自己已有的知识结合调用链一步一步地去看代码，把相关的类也加到了trace中。再经历了一系列的分析，我终于找到了罪魁祸首，是写程序的程序员没有处理每个异常，用通俗的话来说，就是那个异常被吃掉了。当然，在他写代码的时候，可能不会出现这种异常，但是在前面那个程序员做了他的fix后，这种异常就一定会有，而且代码没有处理，所以整个处理的链条就不正常了。

找到这个原因，我按耐不住高兴的心情，给对方的程序员写了一封长长的email，告诉他如何解掉这个defect，把defect转了回去。还顺手给他开了一个defect，因为在调查代码的过程中，我发现在一个隐蔽的地方，当你打开trace log，它就会把用户的密码打印在log中。

不过，这件事情并没有完。又过了若干天，项目经理请我来验证这个defect，我发现他并没有做一个完整的修复方案。问题仍然会重现，只好又一次写了email，叮嘱他解掉那个泄露密码的defect。

当这个defect最后关掉的时候，看了一下defect的history，前前后后竟然经历了半年左右。