QapTcha 滑动验证码工具--工做原理分析

QapTcha 是一个网页上另一种形式的验证码工具，经过拉动滚动条来解锁表单的提交动做。官网的地址已经失效，不知为什么，国内在这里找到：OSCHINA。

QapTcha 演示，点击下载

如下直奔主题，先看工做原理：

从上述时序图可见，当用户进入页面时，Qaptcha调用GeneratePass,分别生成两个字符串，分别是 name（32）和value（7）的值，并向页面注入一个Hidden类型的Input控件，随后，用户滑动Qaptcha触发向服务端的Ajax请求，服务端接收请求后，将传递过来的qaptcha_key(即，GeneratePass生成的32位字符串）新建一个名为 qaptcha_key的Session，用于后续提交动做的验证；而后，服务端返回Session创建是否成功(result{error:true | false}，最后，若result为false，客户端脚本将清空qaptchaInput控件(hidden input)的value。

当用户执行提交操做，客户端将POST一个qaptchaInput的value为空的请求，服务端验证以  Session["qaptcha_key"]是存在，且，值不为空  &&　qaptchaInput的value为空　的状况　为 真，即 经过验证，并执行后续操做；最终释放 Session["qaptcha_key"]。

针对这一原理，与淘宝的注册/登陆中使用的滑动验证工具类同，但，算法大相径庭。 就目前Qaptcha的实现方式而言，做为验证码的代替工具不太可取，“形同虚设”。后续文章将对这一观点做细节分析说明，如下先抛出几个值得思考的问题：

1）创建Session["qaptcha_key"]的请求地址明确得取的状况下，经过模拟POST请求或使用webbrowser的document对象进行模拟网页操做，是否就能在服务端创建这一Session？

2）经过模拟POST请求或使用webbrowser的document对象令qaptchaInput的值为空，是否就无视了服务端的所谓的“真”判断？

3）若是服务端不是简单地创建一个Session，而考虑往客户端返回一些其没法自行构造 ，且，与当前Session惟一对应的值，则，可否更有效杜绝客户端模拟或演算验证所需的项和值？