Callback Rules
HTTP requests have security risks such as DNS hijacking, dynamic ad insertion, data theft, and data modification in a general network environment. The open platform recommends developers using the HTTPS protocol in their callback URLs to ensure data security.
After receiving the callback response from the open platform, the developer verifies the data. Take "Create Service Order Callback" as an example, create a data series in the response, add the appSecret value at the end, and encrypt it with the sha1 algorithm. Please refer to "Code Encryption DEMO" for the demo code.
Callback Encryption Illustration:
{
"content": {}, //message content
"createTime": 1616502610117, // timestamp
"msgType": "event.autox3.order.detection.finish", // message type
"msgSignature": "0354980F3F1162CFD60722", //Sha1 sign value
"msgId": "e6ddea1d-0b8b-24e7-cb26-91c3aa0969db", // message id
"staffInfo": {} // staff info
}
The msgSignature in the example above is the final signature value for proofreading.
The developer needs to return the correct response after receiving the callback from the open platform and passes the verification. The data format is:
{
"data":"",
"errorInfo":"", // error info
"status":0 // 0 stands for successful callback reception
}
In the JSON response above, if the status is 0, the developer has received the response, and the open platform will stop the callback. Conversely, if the open platform server does not receive a normal response, it will initiate a retry.
The open platform will retry a total of six times per the periodic decay law, with intervals of 2s, 4s, 8s, 16s, 32s, and 64s. After six retries, if the correct response is still not received, the open platform will stop the repetition and retain the callback alarm.
Last updated
Was this helpful?