POST V1 signature

When a POST V1 signature is required

HTTP POST requests to OSS support the V1 signature algorithm, which this topic refers to as POST V1 signing. Before you calculate a POST V1 signature, review the following conditions and dependencies:

• Bucket ACL — A PostObject request must carry a signature when the ACL of the destination bucket is public-read or private.

• Form fields — Provide the OSSAccessKeyId, Signature, and policy form fields as a group. If any one of the three fields is present in the form, the other two are also required. For field-level descriptions, see Form fields.

• Where the signature is calculated — The application server calculates the signature and delivers it, together with the upload policy, to the client. The client uses this information to construct the PostObject request.

• Credentials — The signature is calculated from the AccessKey secret. The OSSAccessKeyId form field carries the AccessKey ID of the same AccessKey pair.

Calculate a POST V1 signature

Calculate a POST V1 signature on your application server in the following three steps:

1. Create the policy. Create a UTF-8 encoded policy. For the policy syntax and the conditions that you can declare, see Policy structure.

2. Construct the string to sign (StringToSign). Base64-encode the policy. The resulting string is the string to be signed (StringToSign).

3. Calculate the signature. Use the AccessKey secret to sign the string to be signed. The signing formula is Signature = base64(hmac-sha1(AccessKeySecret,base64(policy))).

The following figure shows the POST V1 signature calculation process.

Example: calculate a POST V1 signature in Java

The following Java example runs the three steps of POST V1 signing against the example policy described in Policy structure. Step 3 calls the OSS Java SDK, which applies the base64(hmac-sha1(AccessKeySecret,base64(policy))) formula to the string to be signed.

import org.apache.commons.codec.binary.Base64;

public class Demo {
    public static void main(String[] args) {
        // Before running this code example, make sure the OSS_ACCESS_KEY_SECRET environment variable is set.
        String accessKeySecret =  System.getenv().get("OSS_ACCESS_KEY_SECRET");

        // Step 1: Create the policy.
        String policy = "{\n" +
                "  \"expiration\": \"2023-12-03T13:00:00.000Z\",\n" +
                "  \"conditions\": [\n" +
                "    {\"bucket\": \"examplebucket\"},\n" +
                "    [\"content-length-range\", 1, 10],\n" +
                "    [\"eq\", \"$success_action_status\", \"201\"],\n" +
                "    [\"starts-with\", \"$key\", \"user/eric/\"],\n" +
                "    [\"in\", \"$content-type\", [\"image/jpeg\", \"image/png\"]],\n" +
                "    [\"not-in\", \"$cache-control\", [\"no-cache\"]]\n" +
                "  ]\n" +
                "}";

        // Step 2: Construct the string to sign (StringToSign).
        String stringToSign = new String(Base64.encodeBase64(policy.getBytes()));

        // Step 3: Calculate the signature.
        String signature = com.aliyun.oss.common.auth.ServiceSignature.create().computeSignature(accessKeySecret, stringToSign);
        System.out.println("signature:" + signature);
    }
}

The signature is printed in the following format. The printed value is a Base64-encoded string that depends on your AccessKey secret and on the exact bytes of your policy, so your output differs from the following sample.

signature:****

Submit the calculated value in the Signature form field of the PostObject request, together with the OSSAccessKeyId and policy form fields.

Form fields

The following form elements are specific to POST V1 signing. For other common form elements, see PostObject form elements. For the conditions under which these fields are required, see When a POST V1 signature is required.

Policy structure

The policy form field is a security policy that defines the permissions and constraints for uploading objects to OSS through an HTML form. The policy is defined in JSON format and restricts upload operations through multiple parameters, such as the allowed bucket name, object prefix, expiration time, allowed HTTP methods, content size limits, and content type restrictions.

The policy must include the expiration and conditions fields, as shown in the following example.

{
  "expiration": "2023-12-03T13:00:00.000Z",
  "conditions": [
    {"bucket": "examplebucket"},
    ["content-length-range", 1, 10],
    ["eq", "$success_action_status", "201"],
    ["starts-with", "$key", "user/eric/"],
    ["in", "$content-type", ["image/jpeg", "image/png"]],
    ["not-in", "$cache-control", ["no-cache"]]
  ]
}

The policy contains the following elements:

• expiration — Specifies the expiration time of the policy in ISO 8601 GMT format. For example, 2023-12-03T13:00:00.000Z means the POST request must be initiated before 13:00 GMT on December 3, 2023.

• conditions — Specifies the valid values for the form fields in the POST request.

The following table describes the fields that you can declare in conditions.