作为 -GWA2 的一个实例， -gMIS 一直运行良好，今天在部署到一个新项目测试运行中，发现一个令人不安的bug，虽很快找到并修复，但就像OpenSSL的heartbleed一样，需要事后反思。
事情缘起这样，新项目部署后，其中一个数据表的记录被不断的更新，数据被清空。由于是部署在一个“伪私有主机”上，无法登陆到服务器进行查询，所以加大了判断和troubleshooting的难度，好在对于 -gMIS 相当熟稔，同时对业务逻辑也很明细，再同时 -gMIS 里能够看到详细的 operatelog , 这样定位起来，即便在“虚拟主机”，看不到访问日志的情况下，基本推测出出错的流程。
错误点在于，由于未知的原因，远程访问的请求拼出类似下面这样的地址：
admin/jdo.php?act=list-addform&id=…
常规情况下，这一请求会被
admin/comm/header.inc
里的判断逻辑所阻隔，并跳转到登录页面，所使用的语句是
header(“Location: LOGIN_PAGE”);
问题恰出在此处，虽然这里设置了 header , 也即在HTTP 的response头部增加了 302 的跳转导向，但！是！ header之后的语句逻辑会照样被执行，也即符合相关条件的记录仍会被更新，由于这个请求是被恶意拼接的，所以相应的数据根本就是错误的，也因此出现了开头的一幕，数据被不断的重置为空，但记录数并没有变，只是项的值被不断的填入为“”。
经上分析测试，在测服务器上快速部署了代码
exit(0);
在发现未登录用户的情况下，随即结束当前页面的业务逻辑，终止进一步操作并将页面处理权由PHP交回到Apache那里去。
虽然是个小bug，并且发现及时，但仍事后感到心有余悸。为何之前没有预料到这样的错误呢？如果没有
exit(0);
执行语句，程序页面在测试时并无任何异常，逻辑仍是按照预期的路线跳转到登录页，只是这种依赖终端浏览器的测试，不能察觉出，实际的mod和act仍旧被执行了。这里只测试了浮表，并未能使用code review的方式进行深入分析每一块逻辑和每一行语句。
软件仍是在不断使用和测试中成长的。
