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


QapTcha 演示，点击下载


以下直奔主题，先看工作原理：


wKioL1ZTWyexmuX3AAC1g-rv9lw772.png

从上述时序图可见，当用户进入页面时，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唯一对应的值，则，能否更有效杜绝客户端模拟或演算验证所需的项和值？