0002-00000101

更新时间:
复制 MD 格式

Problem description

The V2 signature in your request does not match the signature that OSS calculated.

Causes

Your request uses the V2 signature, but the signature value does not match what OSS computes from the same request data.

Examples

The following request uses the V2 signature (OSS2) but provides an invalid signature value:

GET /oss.jpg?x-oss-signature-verion=OSS2&x-oss-access-key-id=nz2pc56s936****&x-oss-expires=1141889120&x-oss-signature=InvlidSignature HTTP/1.1
Host: oss-example.oss-cn-hangzhou.aliyuncs.com
Date: Tue, 20 Dec 2022 08:48:18 GMT

Solutions

Determine how your request is signed, then follow the corresponding steps.

If you use an OSS SDK, the SDK constructs and signs requests for you. Work through the following checks in order and stop when you find the cause:

  1. Check the endpoint format. The endpoint must follow the format http://oss-<region-id>.aliyuncs.com. For example, the valid endpoint for the China (Hangzhou) region is http://oss-cn-hangzhou.aliyuncs.com. For endpoints in other regions, see Regions and endpoints.

  2. Check the AccessKey ID and AccessKey secret. The AccessKey ID and AccessKey secret cannot start or end with a space. Copy the credentials directly from the Alibaba Cloud console and verify there are no leading or trailing spaces.

  3. Check bucket and object naming conventions. A signature mismatch can result from a bucket or object name that violates naming conventions, because the name is part of the string that OSS signs.

    Bucket naming conventions:

    • Must be unique across all of OSS

    • Can contain lowercase letters, digits, and hyphens (-)

    • Must start and end with a lowercase letter or digit

    • Must be 3–63 characters in length

    Object naming conventions:

    • Must be encoded in UTF-8

    • Must be 1–1,023 bytes in length

    • Cannot start with a forward slash (/) or a backslash (\\)

    • Is case-sensitive

  4. Check the signature method. If your application constructs part of the request manually:

    • If your environment supports OSS SDKs, use the SDK signature method. See Overview.

    • If your environment does not support OSS SDKs, write code to calculate the signature and add it to RESTful API requests. See Overview.

  5. Check for proxy-injected headers. If your request passes through a proxy server, the proxy may add or modify headers after you sign the request. Headers added after signing are not included in the StringToSign that your code computed, but OSS includes all received headers in its own calculation — causing a mismatch. Use a network inspection tool such as a packet capture tool or an HTTP proxy debugger to compare the headers your client sends with the headers OSS receives. Remove or account for any headers the proxy adds.

If you sign requests manually (self-signed mode), use the StringToSign to pinpoint the mismatch:

If the server returns a response that contains the StringToSign parameter, compare this value with the string your code constructed before signing. A character-level difference between the two strings identifies exactly where your V2 signature calculation diverges from what OSS expects.

For the V2 StringToSign structure and a reference implementation, see: