加密与签名

平台与第三方的交互在公网环境通常采用 HTTPS 方式进行通讯，在局域网环境也可以采用 HTTP 方式进行通讯。尽管如此，为了进一步增强某些核心业务（例如退款）的安全性，接口仍然提供了必要的数据编码及签名验证的方案，具体如下：

1、通过 HTTP 内容协商机制窄化接口的响应条件，例如：

POST http://api.example.com/foo/1
Accept: application/zw-packet

即接口调用方在发起请求时，必须在请求头中包括 Accept: application/zw-packet，否则服务端会拒绝响应。相应的，服务端的回应报文中也包含相应的响应头，以便接口调用方拒此做出正常的解码处理。

2、使用 POST 方法，以便将请求参数及响应结果放在报文体中，采用非明文格式传递。

参照图文说明： 加密与签名

报文体的生成规则如下：

  1. 全部报文均由小写 HEX 字符组成；
  2. 前 32 个字符为混淆字符串，无意义，封包时可以通过对当前时间做 md5 运算生成，解包时直接舍弃，不参与后续逻辑；
  3. 接下来的 32 个字符是签名，生成规则第 5 步描述；
  4. 去除前 64 个字符，剩余为正式报文。正式报文由 UTF-8 编码的 JSON 字符串生成，具体步骤如下：
    1. 将 JSON 字符串转换成 byte 数组；
    2. 将 byte 数组转换成小写 HEX 字符串。
  5. 生成第 3 步描述的签名，具体步骤如下：
    1. 对平台分给自己的调用密码作 sha1 运算，生成 40 个小写 HEX 字符；
    2. 在第 4.2 步生成的 HEX 字符串后追加上前述 40 个 HEX 字符，形成新的字符串；
    3. 对上一步生成的字符串做 md5 运算，生成 32 个小写 HEX 字符串，即第 3 步的签名。

以下是示例数据。假定接口调用方的调用密钥为 123，并且要发送如下请求参数到服务端：

{ "a": 1, "b": "ok" }

则按照上述生成规则编码后，其应提交的请求报文体为：

ff5229f14603a81cf14cc43496d5049f2f95421c134184f7503dd18
e092a02b87b2261223a312c202262223a226f6b227d

相关代码示例如下：

results matching ""

    No results matching ""