请求签名

在使用 T1 后端云 RESTful API 时，必须通过请求签名进行身份验证，防止被恶意攻击。所有接口请求签名格式都是一致的，所以您可以封装一个请求方法即可完成所有 T1 后端云 RESTful API 的请求。

说明

在前面的文档中，所有接口相关的文档，都是以下格式的：

cURL

curl --location --request GET 'http://您已备案域名/v5/classes/<collection_name>?page=1&size=10' \
--header 'X-T1Y-Application-ID: {{app_id}}' \
--header 'X-T1Y-Api-Key: {{api_key}}' \
--header 'X-T1Y-Safe-NonceStr: {{客户端随机生成的32位随机码}}' \
--header 'X-T1Y-Safe-Timestamp: {{Unix时间戳，精确到秒}}' \
--header 'X-T1Y-Safe-Sign: {{MD5(path+app_id+api_key+客户端随机生成的32位随机码+Unix时间戳+Secret_Key)}}'

cURL-Windows

curl --location --request GET "http://您已备案域名/v5/classes/<collection_name>?page=1&size=10" ^
--header "X-T1Y-Application-ID: {{app_id}}" ^
--header "X-T1Y-Api-Key: {{api_key}}" ^
--header "X-T1Y-Safe-NonceStr: {{客户端随机生成的32位随机码}}" ^
--header "X-T1Y-Safe-Timestamp: {{Unix时间戳，精确到秒}}" ^
--header "X-T1Y-Safe-Sign: {{MD5(path+app_id+api_key+客户端随机生成的32位随机码+Unix时间戳+Secret_Key)}}"

在以上代码中，使用 cURL 请求接口时，需要携带以下 请求头 参数：

• X-T1Y-Application-ID：应用 ID
• X-T1Y-Api-Key：应用 API Key
• X-T1Y-Safe-NonceStr：客户端随机生成的 32 位随机码
• X-T1Y-Safe-Timestamp：Unix 时间戳，精确到秒
• X-T1Y-Safe-Sign：签名

这些请求头中最重要的就是签名（X-T1Y-Safe-Sign），那么签名是怎么来的呢？

签名生成

签名生成需要以下参数：

• path：接口路径（不包含 GET 请求参数）
• app_id：应用 ID
• api_key：应用 API Key
• nonce_str：客户端随机生成的 32 位随机码
• timestamp：Unix 时间戳，精确到秒
• secret_key：应用 Secret Key

将以上的这些参数通过有序的拼接，然后通过 MD5 加密，就能得到签名。

签名有效期

为了确保请求安全，每次请求，T1 后端云服务器都会判断请求到达服务器的时间，如果超出 ±10秒，服务器就会拒绝当前请求。这个有效期，很好的防止了恶意攻击者的 重放攻击。

签名例子

假设您需要使用 http://您已备案域名/v5/classes/<collection_name>?page=1&size=10 接口分页查询 T1 后端云应用数据库中的数据时，您的应用 ID 为 1001，API Key 为 abc，Secret Key 为 123，那么签名应该为：

MD5('/v5/classes/<collection_name>1001abc' + 客户端随机生成的 32 位随机码 + Unix 时间戳，精确到秒 + '123')

因为是 GET 请求，所以我们不需要请求参数 ?page=1&size=10，如此一来，您便得到了一个 32 位的 MD5 值，该值就是签名。

重置 Secret Key

通过以上的例子，您可能已经非常清楚 Secret Key 的作用，Secret Key 并不会在网络中传输，如果您在客户端中使用时，建议您使用一些加密方法，将 Secret Key 进行加密，而不是明文存放到客户端代码中，这样 Secret Key 的安全性就得到了保障。但如果您的 Secret Key 还是不小心泄露了，那么也没有关系，您可以通过仪表盘 -> 应用 -> 设置 -> 应用密钥 中重置 Secret Key。