签名说明

由于 JU 需要为第三方平台提供一些开放性的接口，所以需要接口的数据安全问题，比如数据是否被篡改，数据是否已过时，数据是否可以重复提交，接口在某个时间内访问频率等问题。其中数据是否被篡改是最重要的。

1、线下分配 appkey 和 secretkey，针对不同的调用，提供不同的 appkey 和 secretkey

2、加入 timestamp(时间戳)，其值应当是请求发送时刻的 unix 时间戳(毫秒)，数据的有郊时间根据此值来计算。

3、加入 signature(数据签名)，所有数据的签名信息。

4、加入 recvwindow(自定义请求有效时间)，有效时间目前相对简单统一固定为某个值，比如：同 api 同 appid 下 10 分钟内数据都有郊，此处可以再进步优化到具体单个 api 有效时间都不相同。

服务器收到请求时会判断请求中的时间戳，最长 60 秒，默认为 5 秒，如果是 5000 毫秒之前发出的，则请求会被认为无效。这个时间窗口值可以通过发送可选参数 recvWindow 来自定义。 另外，如果服务器计算得出客户端时间戳在服务器时间的‘未来’一秒以上，也会拒绝请求。 关于交易时效性 互联网状况并不 100%可靠，不可完全依赖,因此你的程序本地到 JU 服务器的时延会有抖动. 这是我们设置 recvWindow 的目的所在，如果你从事高频交易，对交易时效性有较高的要求，可以灵活设置 recvWindow 以达到你的要求。

不推荐使用 5 秒以上的 recvWindow

5、加入 algorithms (签名方法/算法)，用户计算签名是基于哈希的协议，此处默认使用 HmacSHA256。具体支持那些协议，请参见下面表格中所列出

字段名	是否必须	示例	说明
validate-appkey	true	dbefbc809e3e83c283a984c3a1459732ea7db1360ca80c5c2c8867408d28cc83
validate-timestamp	true	1641446237201
validate-signature	true	0a7d0b5e802eb5e52ac0cfcd6311b0faba6e2503a9a8d1e2364b38617877574d
validate-recvwindow	false	5000(millisecond)
validate-algorithms	false	HmacSHA256	HmacMD5、HmacSHA1、HmacSHA224、HmacSHA256、HmacSHA384、HmacSHA512，默认为：HmacSHA256
api-version	false	1.0	Reserved, API version number
validate-signversion	false	1.0	Reserved, signature version number