一次更新故障引发的思考

新接手项目,第一次发布到线上,说实在的心里还是挺高兴的,可惜异地办公多多少少会有些不方便。当然这些都不重要,重要的是这次上线以后引发了一个故障,这个时候比较有经验的人员却不在公司。我作为其中一员,必须接手这个问题,然后在处理问题的过程中,到最后发现问题原因并解决,以及整个过程中和客户的电话沟通。从中引出了一些想法,一些思考。唠唠叨叨就在这写上几句。
1、不要相信流入的数据
关于这个问题,这次的故障,也可以归结为,用户录入数据导致的。sql注入、xss漏洞等等这些问题大多数都是因为忽略了对流入数据的验证和处理导致的。而这一次根本的原因在于用户输入的数据存在特殊字符“\n\t”。原先的业务逻辑是直接对数据进行页面绑定,这次更新为了提升用户体验,采用了ajax方式对列表进行局部刷新,页面则使用seajs,结合jquery进行渲染。因为特殊字符的存在。导致ajax活到到了json数据知道渲染出错,其结果列表页一直无法访问。其解决方案为:在转换为json之前过滤掉特殊字符(在存储时不能去掉,但是可以转义,因为你需要保存数据的格式)。
2、根据项目的受众分配工作重心
本次更新分为前台和后台两个部分,按照开发的工作量来分,后台的工作量相对较大。简要说明一下前台后台的概念,在这前台指给客户使用的子系统,而后台则是内部使用的子系统,两个系统公用数据。按照开发量来说,后台应该分配更多的时间进行开发,测试。是的的确是这样子。可是问题来了,上线之后因为一个特殊字符的问题导致了前台异常。按责任划分这应该属于开发的责任,但是测试也通过了没有发现问题,最终问题暴露于客户使用过程中。可能这样说一个标题并不恰当,但是想要表达的一个意思就是,在操作过程中需要考虑一下影响面,多留心。如果能做到没有问题那再好不过,但是如果做不到那么相应的要在那个部分多留心。
3、不要相信用户的行为与我们一样
结合这次的问题,想起一件事情,关于数据录入。比如:内容有:标题、详细内容。布局的时候标题在上,详细内容在下。那么我们在填写内容的时候,也应该是先填写标题,在填写详细内容啊。可是这只是我们想的,理所应当的。如果标题不是必填项,可以从详细内容截取20个作为标题读出来。那么这个时候客户一次偶然发现了可以直接填写内容,而不用填写标题。好了,只需要填写内容一步到位的提交数据,省事。这打破了我们从标题、到内容的这个操作过程,而详细内容可能包括制表符等这些特殊字符,使用js渲染页面必然出现问题。面对这个问题,一个是改业务,标题必填,但是这个操作不见得可行;第二个那就只能在输出json的时候进行特殊字符的过滤。
PS:第一次发布就遇上这个事情,写这段东西,仅当做个教训,提醒自己多用心。好好学习,天天向上。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据