Native HTTPS call

When to use native HTTPS calls

With native HTTPS calls, you implement the signature process yourself and assemble the request URL, body, headers, and parameters.

Native HTTPS calls are recommended only in the following scenarios. In all other cases, use an SDK call instead.

• Client size — You use the service directly in an app and have strict requirements on client size.

• Dependency version — You must use a specific version of a dependent library package that cannot be easily upgraded.

Prerequisites

• An AccessKey pair issued by Alibaba Cloud. Create and manage AccessKey pairs on the Alibaba Cloud website.

Endpoints and request attributes

The following table lists the public endpoint and the VPC endpoint of Fraud Detection in each region.

The following table lists the fixed attributes of a native HTTPS request to Fraud Detection.

Sign a request

Fraud Detection authenticates every request, so each request must carry a Signature parameter.

Authentication is based on an AccessKey pair. The AccessKey ID identifies the requester. The AccessKey Secret is the key that produces the signature and lets the server verify the request, so keep it confidential.

To sign a request, follow these steps:

1. Construct a canonicalized query string from the request parameters.

   1. Sort all request parameters in lexicographical order by parameter name. These parameters include all common request parameters and any operation-specific parameters. The canonicalized query string in the request must not contain the Signature parameter itself.

   2. URL-encode the parameter names and values by using the UTF-8 character set. The URL encoding rules are as follows:

      • Do not encode uppercase letters (A-Z), lowercase letters (a-z), digits (0-9), hyphens (-), underscores (_), periods (.), or tildes (~).

      • Encode other characters into the %XY format, where XY is the two-digit hexadecimal representation of the character's ASCII code. For example, a double quotation mark (") is encoded as %22.

      • Encode extended UTF-8 characters into the %XY%ZA... format.

      • Encode a space as %20 instead of a plus sign (+).

      Note

      Most standard libraries for URL encoding, such as java.net.URLEncoder in Java, follow the application/x-www-form-urlencoded MIME type. You can use these libraries for encoding. After encoding, replace the plus sign (+) with %20, the asterisk (*) with %2A, and %7E back to a tilde (~) to produce a string that conforms to the preceding rules.

   3. Concatenate the encoded parameter names and values with an equal sign (=).

   4. Concatenate the resulting strings in lexicographical order by parameter name with ampersands (&) to obtain the canonicalized query string.

2. Use the canonicalized query string from the previous step to construct the string-to-sign as follows:

   StringToSign =
   HTTPMethod + "&" +
   percentEncode("/") + "&" +
   percentEncode(CanonicalizedQueryString)

   • HTTPMethod is the HTTP method used for the request, such as POST.

   • percentEncode("/") is the encoded value of the forward slash (/), which is %2F.

   • percentEncode(CanonicalizedQueryString) is the canonicalized query string from step 1, encoded according to the URL encoding rules in step 1.b.

3. Calculate the HMAC value of the string-to-sign as defined in RFC 2104. Use the SHA1 hash algorithm and a key that consists of your AccessKey Secret followed by an ampersand (&, ASCII 38).

4. Base64-encode the resulting HMAC value. The result is the signature (Signature).

5. Add the signature to the request as the Signature parameter. The request is now signed.

   Important

   When you submit the signature to the Fraud Detection server as a request parameter, URL-encode it as specified in RFC 3986, like every other parameter.