摘要：阿里云的服務(wù)數(shù)據(jù)風控下面有項滑動驗證適合有人機驗證場景的應(yīng)用接入所謂滑動驗證是在需要進行人機識別時前端出現(xiàn)驗證滑塊通過拖動滑塊到末尾實現(xiàn)驗證如果阿里云認為此次驗證風險稍高可能出現(xiàn)點擊漢字的認證等如果風險太高驗證會直接拒絕集成過程基本是按照阿

阿里云的服務(wù) 數(shù)據(jù)風控下面有項滑動驗證, 適合有人機驗證場景的應(yīng)用接入.

所謂滑動驗證, 是在需要進行人機識別時, 前端出現(xiàn)驗證滑塊, 通過拖動滑塊到末尾, 實現(xiàn)驗證. 如果阿里云認為此次驗證風險稍高, 可能出現(xiàn)點擊漢字的認證等, 如果風險太高, 驗證會直接拒絕.

集成過程基本是按照 阿里云官方文檔 來進行的.

開通滑動驗證服務(wù)之后, 阿里云控制臺會給出前后端的示例代碼, 其中appkey是根據(jù)用戶不同分配的不通的key.

前端代碼如下所示:

  
  

  
  
  
    










  

    

      用戶名：
      
    

    

      密碼：
      
    

    

      

    

    
    
    
    
    

      
    
  

其中標記不可更改的地方就不要更改. 可以看到, 在驗證通過之后, console會打印出session, sig, token等幾個驗證返回變量, 連同scene一起, 通過表單返回業(yè)務(wù)后臺, 由后臺調(diào)用阿里云滑動驗證服務(wù)進行校驗.

python后臺方面, 首先需要

pip install aliyun-python-sdk-jaq

安裝阿里云滑動驗證的python sdk
python的后臺代碼大致如下:

# coding: utf-8
import requests
from aliyunsdkcore import client
from aliyunsdkjaq.request.v20161123 import AfsCheckRequest
from aliyunsdkcore.profile import region_provider
from app.libs.configure import config

region_provider.modify_point("Jaq", "cn-hangzhou", "jaq.aliyuncs.com")

clt = client.AcsClient(config.ALIYUN_OSS_ACCESS_KEY, config.ALIYUN_OSS_ACCESS_SECRET, "cn-hangzhou")


def check_aliyun_captcha(session, sig, token, scene):
    request = AfsCheckRequest.AfsCheckRequest()
    # 必填參數(shù)：請求來源： 1：Android端； 2：iOS端； 3：PC端及其他
    request.set_Platform(3)
    request.set_Session(session)
    request.set_Sig(sig)
    request.set_Token(token)
    request.set_Scene(scene)
    result = clt.do_action_with_exception(request)
    print result

這只是個簡單示例, print出了返回結(jié)果. 這個返回結(jié)果是json序列化的string, 需要將其反序列化進行結(jié)果判定. 如果Data元素是true的話, 證明校驗通過, 可以進行下面的業(yè)務(wù)邏輯.
同樣的, 這里還有一點沒有處理, 就是do_action_with_exception的拋出ServerException的問題. 應(yīng)當catch處理.

如果驗證通過的話, 阿里云返回:

{"Data":true,"ErrorMsg":"success.","ErrorCode":0}

但只能驗證一次, 第二次同樣參數(shù)執(zhí)行的話, 會返回:

{"Data":false,"ErrorMsg":"invalid sig parameter.","ErrorCode":400}

是為了防止暴力嘗試等.

同時必須說明, 阿里云的這項服務(wù)我認為并不穩(wěn)定, 集成中間出現(xiàn)了一直invalid sig的報錯. 后來經(jīng)與技術(shù)支持溝通才ok. 并且這塊的文檔友好程度等還比較欠缺.

另: 我還按照阿里云api文檔(滑動驗證api, 公共參數(shù), 簽名機制)的說明寫了段代碼, 不使用aliyun-python-sdk, 手動拼接請求.同樣發(fā)現(xiàn)了很多問題.
比如文檔中有一段

這個簽名值應(yīng)當不是隨便寫的. 使用文檔中要求的HMAC-SHA1簽名算法, 無論是用python像如下這樣書寫:

from hashlib import sha1
import hmac
from base64 import b64encode

hashed = hmac.new("testsecret&", string_to_sign, sha1)
signature = b64encode(hashed.digest())
print signature

還是像如下用Java算簽名:

import javax.crypto.Mac;  
import javax.crypto.SecretKey;  
import javax.crypto.spec.SecretKeySpec;
import org.apache.commons.codec.binary.Base64;  
  
public class HMACSHA1 {  
  
    private static final String MAC_NAME = "HmacSHA1";    
    private static final String ENCODING = "UTF-8";    

    public static byte[] HmacSHA1Encrypt(String encryptText, String encryptKey) throws Exception {           
        byte[] data=encryptKey.getBytes(ENCODING);  
        SecretKey secretKey = new SecretKeySpec(data, MAC_NAME);   
        Mac mac = Mac.getInstance(MAC_NAME);   
        mac.init(secretKey);    
        byte[] text = encryptText.getBytes(ENCODING);    
        return mac.doFinal(text);    
    }
    
    public static void main(String[] args) throws Exception{
        byte[] bytes = HMACSHA1.HmacSHA1Encrypt("string_to_sign", "testsecret&");
        System.out.println(Base64.encodeBase64String(bytes));
    }
} 

string_to_sign用文檔中給出的替換, 我的兩段程序算出的是一致的, 但都跟文檔中給出的不一致. 不清楚為何基礎(chǔ)算法會不一致, 難道是文檔不夠新.

如果我用python如下根據(jù)api文檔實現(xiàn)自己的后臺請求方法的話:

import random
from urllib import quote
from hashlib import sha1
import hmac
import requests
from base64 import b64encode
import datetime

def utcnow_isostr():
    dt = datetime.datetime.utcnow()
    return datetime.datetime.strftime(dt, "%Y-%m-%dT%H:%M:%SZ")

def quote_ali(element):
    return quote(str(element)).replace("+", "20%").replace("*", "2A%").replace("%7E", "~")

def build_afs_check_request(session, sig, token, scene):
    m = dict()
    m["Action"] = "AfsCheck"
    m["Format"] = "JSON"
    m["Version"] = "2016-11-23"
    m["AccessKeyId"] = config.ALIYUN_OSS_ACCESS_KEY
    m["SignatureMethod"] = "HMAC-SHA1"
    m["Timestamp"] = utcnow_isostr()
    m["SignatureVersion"] = "1.0"
    m["SignatureNonce"] = str(int(random.random()*1000000))
    m["token"] = token
    m["sig"] = sig
    m["session"] = session
    m["scene"] = scene
    m["platform"] = 3
    ks = m.keys()
    ks.sort()
    query_list = list()
    for k in ks:
        query_list.append(k + "=" + quote_ali(m[k]))
    string_to_sign = "GET&%2F&" + "&".join(query_list)
    print string_to_sign
    base_query_string = "&".join(query_list)
    hashed = hmac.new(config.ALIYUN_OSS_ACCESS_SECRET + "&", string_to_sign, sha1)
    signature = b64encode(hashed.digest())
    print signature
    url = "http://jaq.aliyuncs.com/?{}&Signature={}".format(base_query_string, quote_ali(signature))
    print url
    return url

def custom_check_aliyun_captcha(session, sig, token, scene):
    url = build_afs_check_request(session, sig, token, scene)
    resp = requests.get(url)
    print resp.content

這么去請求的話會報Signature不一致, 果不出所料.

基于以上詭異的表現(xiàn), 我覺得阿里云滑動驗證作為外部服務(wù)并不友好或成熟. 更傾向于用自己做的一些驗證碼服務(wù), 雖然會簡單些, 更容易被攻破, 至少穩(wěn)定, 提供的qps更高.