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惟一對應的值，則，可否更有效杜絕客戶端模擬或演算驗證所需的項和值？