|
签名规则一、API签名算法及工具API签名算法及工具二、API签名串组装规则在1688开放平台，url请求的多个参数都要参与签名（与文件上传有关的api中，文件字节流那个参数不参与签名），下面以两个参数为例，假设请求的url格式如下所示： http://gw.open.1688.com/openapi/param2/1/system/currentTime/1000000?b=2&a=1（appKey=1000000， 假设 secretKey=test123） 参照签名算法说明，签名串s组装规则为： 1、 构造签名因子：urlPath。url 中的一部分，我们称之为urlPath，从协议（param2）开始截取，到“?”为止，urlPath=param2/1/system/currentTime/1000000 2、 构造签名因子：拼装的参数。参数 b=2&a=1，首先将参数的key和value拼在一起，得到b2和a1，然后按照首字母排序，得到a1和b2，最后按顺序拼在一起得到a1b2 3、 合并两个签名因子。把前两步的字符串拼起来，得到s = param2/1/system/currentTime/1000000a1b2 4、 对合并后的签名因子执行hmac_sha1算法。 Signature=uppercase (hex (hmac_sha1 (s, secretKey)) 得到签名33E54F4F7B989E3E0E912D3FBD2F1A03CA7CCE88 ——secretKey为签名密钥，与urlPath中的appKey（1000000）对应 ——hmac_sha1为通用的hmac_sha1算法，各编程语言一般都对应类库 ——hex为转为十六进制 ——uppercase为转为大写字符 说明：API签名算法主要是使用urlPath和请求参数作为签名因子进行签名，主要针对api 调用 三、参数签名算法及工具参数签名算法及工具四、参数签名串组装规则在1688开放平台，用户在客户端访问app时app发起的授权请求url如下所示 ：（ 注意：只有客户端或WEB端授权流程中的"app发起授权请求"这一步的签名才使用此规则，参见 客户端流程详情） http://gw.open.1688.com/auth/authorize.htm?client_id=YOUR_CLIENT_ID&site=china&redirect_uri=YOUR_REDIRECT_URL&state=YOUR_PARAM&_aop_signature=SIGNATURE 注意：此处访问的是授权页面authorize.htm，并不是api调用，所以没有urlPath，不能用API签名算法，只是用请求参数作为签名因子进行签名。请求参数的拼装算法跟API签名一致 假设用户授权请求的参数为 client_id=10000&site=china&redirect_uri=http://localhost:8888&state=test（ client_id为appKey，对应的签名密钥假设为 client_secret=abcd）， 那么签名串的组装规则为 ： 1、 构造签名因子：拼装的参数 。 参数 client_id=10000&site=china&redirect_uri=http://localhost:8888&state=test， key和value拼在一起得到 client_id10000&sitechina&redirect_urihttp://localhost:8888&statetest， 然后按照首字母排序，排序后为 client_id10000&redirect_urihttp://localhost:8888&sitechina&statetest， 然后将排序后的数组拼在一起 ，得到最终的签名因子 data=client_id10000redirect_urihttp://localhost:8888sitechinastatetest 2、 对最终的签名因子执行hmac_sha1算法 。 Signature=uppercase (hex (hmac_sha1 (data, client_secret)) 得到签名CA538FE6B2180496B77EB46D0EBB5A2EA7A2418B ——client_secret为签名密钥，与值为10000（client_id参数的值）的appKey对应 ——hmac_sha1为通用的hmac_sha1算法，各编程语言一般都对应类库 ——hex为转为十六进制 ——uppercase为转为大写字符 说明：参数签名算法只使用请求参数作为签名因子进行签名，仅针对客户端或WEB端授权时请求临时令牌code |
