Signature Algorithm v2
Applying for Security Credentials
The security credential used in this document is a key, which includes an accessKeyId and an accessKeyPassword.
AccessKeyId: used to identify the API caller, which is just like a username.
AccessKeyPassword: used to authenticate the API caller, which is just like a password.
You must keep your security credentials private and avoid disclosure; otherwise, your assets may be compromised. If they are disclosed, please disable them as soon as possible.
You can apply for the security credentials according to Zenlayer Docs.
Signature Calculation Process
Zenlayer Open API v2 supports POST requests. Only Content-Type: application/json
is supported. The API is called in JSON format.
The following uses querying the list of bare metal instances in the Hong Kong region as an example to describe the steps of signature splicing.
Assuming that your AccessKeyId and AccessKeyPassword are AKIDz8krbsJ5yKBZQpn74WFkmLPx3
and Gu5t9xGARNpq86cd98joQYCN3
, respectively, if you want to view the status of the instance in the Hong Kong region whose bare metal instance name is "unnamed", then the request may be:
Request Headers:
Key | Explanation | Example |
---|---|---|
X-ZC-Timestamp | Request timestamp in second |
|
X-ZC-Version | API version number |
|
X-ZC-Action | Request action |
|
X-ZC-Signature-Method | Signature method |
|
Authorization | Authentication process |
1. Concatenating the CanonicalRequest String
Concatenate the canonical request string (CanonicalRequest) in the following pseudocode format:
Field Name | Explanation |
---|---|
HTTPRequestMethod | HTTP request method (POST). |
CanonicalURI | URI parameter. Slash ("/") is used here. |
CanonicalQueryString | The query string in the URL of the originating HTTP request. This is always an empty string “” for POST requests. |
CanonicalHeaders | Header information for signature calculation. Custom headers can be added to participate in the signature process to improve the uniqueness and security of the request. Concatenation rules:
The calculation result in this example is: |
SignedHeaders | Header information for signature calculation, indicating which headers of the request participate in the signature process (they must each individually correspond to the headers in CanonicalHeaders).
The value in this example is |
HashedRequestPayload | Hash value of the request payload (i.e., the body, such as |
2. Concatenating the String to Be Signed
The string to sign is concatenated as follows:
Field Name | Explanation |
---|---|
Algorithm | Signature algorithm, which is currently always |
RequestTimestamp | Request timestamp, i.e., the value of the common parameter |
HashedCanonicalRequest | Hash value of the CanonicalRequest string concatenated in the steps above. The pseudocode for calculation is Lowercase(HexEncode(Hash.SHA256(CanonicalRequest))). The calculation result in this example is |
According to the preceding rules, the string to be signed obtained in the example is as follows:
3. Calculating the Signature Based on AK and StringToSign
Calculate the derived signature key with the following pseudocode:
Field Name | Explanation |
---|---|
AccessKeyPassword | The original AccessKeyPassword, i.e., |
StringToSign | The result obtained in Step 2. |
4. Concatenating the Authorization
The Authorization is concatenated as follows:
Field Name | Explanation |
---|---|
Algorithm | Signature algorithm, which is always |
AccessKeyId | The AccessKeyId in the key pair, i.e., |
SignedHeaders | Header information for signature calculation (see above), such as |
Signature | Signature value. The calculation result in this example is |
Last updated