在刷票软件盛行的环境下,验证码的出现可以说大量减少了这些软件对网站的访问和恶意注册等现象的发生,但是有时候太严密的验证码设计会让用户也受到伤害,下面我们就一起来思考一下,验证码功能设计的意义。
思考一:不要将责任推卸给用户
不知道你有没有想过,让用户辨别和输入扭曲的验证码,其实是因为服务提供方的能力欠缺,无法静默区分人和机器,而输入验证码本身,这一 *** 作对用户来说其实并无价值。
有一次我接到用户打来电话,抱怨自己搞不定验证码。我向他解释我们正在被攻击,所以临时调高了验证码的级别。电话的后,我习惯性地向他道歉,用户却很体贴地安慰我说没必要道歉,毕竟被攻击不是我们的错。
当时我心头一热,脸上一红。他说的没错,被攻击确实不是我们的错,但更不是用户的错,让他们付出成本,花费时间,去辨别图片里的那个圆圈究竟是O还是0还是6,其实就是让他们承担我们本应该承担的责任。
举一反三,如果再激进一点考虑,我们的软件服务中还有不少推卸责任的设计,比如:让用户在成千上万的商品中筛选和比价,比如:各种复杂的界面参数设置和兴趣选择。要是想得再发散一点,所有的银行账户密码似乎也没有必要,超市排队也是一样。
如果用户不需要付出筛选和比价的成本,或不需要花费精力记住账户密码,却可以享受到同样高质量的服务,是不是更好呢?
基于这样的思考,我们是不是应该马上去掉这些推卸责任的设计,比如:想出更复杂的方案,替代现有的验证码机制呢?
这是关于验证码的二个思考。
思考二:方案选择的平衡
有效的设计确实未必是好设计,比如:我自己曾经参与设计的产品中也用到验证码,而且在某些特殊阶段(像刚才提到的被定向攻击),我们还会升级验证码机制,让验证码出现的频率更高,而且更加难以辨认,从而在某些关键入口抵抗一些有针对性的攻击。
这一策略是有效的,但对用户的伤害也很大,升级验证码机制后,用户登录过程中耗费的时间会显著增加,通过率也会下降,还有大量的用户抱怨一股脑地涌进来。
然而从服务提供方的角度来看,它却用低的成本快速地解决了当时面临的问题。电脑培训认为这是产品设计方案选择过程中不得不做出的“平衡”,很多时候我们没有办法一时间实施对用户的完美方案,这就需要在产品利益和用户利益之间,找到微妙的动态平衡点。
先建1个ASP文件,生成1个随机数,将其保存进Session,并这个随机数动态生成为图片文件。在验证的页面验证用户提交的验证码是否跟前面保存在Session里面相符,若相符则验证胜利。否则验证失败,验证失败的同时将Session值清空。以上内容可以去网上搜索1个现成的文件代码来用。然后就是在你登录的页面调用这个动态生成的图片文件。 查看原帖>>欢迎分享,转载请注明来源:内存溢出
评论列表(0条)