tencent cloud

APIs

Request Signature

Baixar
Modo Foco
Tamanho da Fonte
Última atualização: 2026-06-02 10:54:07

Feature Introduction

In Tencent Cloud Object Storage (COS), you can send HTTP anonymous requests or HTTP signed requests to COS via the REST API. For signed requests, the COS server authenticates the requester's identity. Authentication for COS is performed using a custom scheme based on the HMAC (Hash Message Authentication Code) key.
Signed requests and anonymous requests are detailed as follows:
Signed request: An HTTP request carries a signature. Upon receiving the message, the COS server authenticates the identity. If authentication succeeds, the server accepts and executes the request. Otherwise, it returns an error message and discards the request.
Anonymous request: An HTTP request carries no identity or authentication information. You perform the HTTP request operation via the REST API.
For information on how to create a request, see Creating a Request Overview.

Applicable Scenarios

In scenarios where COS is used, for data that needs to be published externally, you can typically set objects to public read and private write. This means everyone can view them, while only accounts specified by the ACL policy can write. In this case, you can combine the ACL policy with API request signatures to authenticate access and control operation permissions and validity periods.
In scenarios where signatures are used, you can implement multi-faceted security protection for API requests:
Requester identity authentication: Verify the requester's identity through their unique ID and key.
Transmitted data tampering prevention: Signs and verifies data to ensure the integrity of the transmitted content.
Signature theft prevention: Sets a validity period for the signature to avoid its theft and reuse.
In COS, there are three methods for request signing. We recommend using Method 1 and Method 2:
Method 1: SDK Signature: This method is suitable for scenarios where developers directly use the SDK to request COS.
Method 2: Signature URL: This method is suitable for scenarios where COS users directly access COS via a signed URL.
Method 3: Online Signature Tool: This method is suitable for scenarios such as temporarily generating signed URLs or understanding the signature algorithm.

Must-Knows

This document applies only to the COS XML version.
This document does not apply to HTTP requests for POST Object.
This document applies only when you intend to perform secondary development using the raw API and need to follow the steps described herein.

Method 1: SDK Signing

The COS SDK has implemented the signature functionality. You do not need to concern yourself with signature issues when using the SDK to initiate requests or obtain signatures. If you need to implement the signature yourself or understand the specific implementations in various languages, you can refer to the signature implementation files in the respective language SDKs:
SDK
Signature Implementation File
Android SDK
C SDK
C++ SDK
.NET(C#) SDK
IQCloudSigner.cs (class CosXmlSigner)
Go SDK
iOS SDK
Java SDK
JavaScript SDK
util.js (getAuth)
Node.js SDK
util.js (getAuth)
PHP SDK
Python SDK
Mini Program SDK
util.js (getAuth)

Method 2: Signed URL

The SDK for each language currently supported by COS provides the feature to generate a signed URL. The generated URL contains a signature with a limited validity period, and this signature supports PUT or GET requests. Therefore, you can directly use this URL to upload or download objects without generating an additional signature.
When generating a signed URL for upload, you can also specify headers such as Content-Type or Content-MD5 to restrict the media type of the upload or to ensure the uploaded content matches the specified content. For details on request header settings during upload, refer to the PUT Object documentation.
When generating a signed URL for download, you can also specify the response-xxx request parameter to temporarily modify the relevant headers in the response during download. For details on request parameter settings during download, refer to the GET Object documentation.
For detailed information on generating signed URLs with each language SDK, see the following SDK documentation for each language:
Note:
We recommend that you use temporary keys to generate pre-signed URLs. This approach, which leverages temporary authorization, further enhances the security of requests such as pre-signed uploads and downloads. When applying for temporary keys, follow the principle of least privilege to prevent the exposure of resources beyond the target bucket or object.
If you must use a permanent key to generate a pre-signed URL, we recommend that you limit the key's permissions to upload or download operations only to mitigate risks.

Method 3: Online Signing Tool

COS currently provides the COS Signature Tool. You can use this tool to temporarily generate a signature or to reference the signature generation process. For detailed usage instructions, see the COS Signature Tool documentation.

Signature Algorithm Principles and Usage

Preparations

Signature Calculation

Using a Signature

Signed HTTP requests sent to COS through the RESTful API can pass the signature in the following ways:
1. Through the standard HTTP Authorization header, for example, Authorization: q-sign-algorithm=sha1&q-ak=...&q-sign-time=1557989753;1557996953&...&q-signature=...
2. When they are used as HTTP request parameters, ensure they are URL-encoded, for example, /exampleobject?q-sign-algorithm=sha1&q-ak=...&q-sign-time=1557989753%3B1557996953&...&q-signature=...
Note:
The preceding example uses ... to omit some specific signature details.
If temporary security credentials (temporary keys) are used when the signature is calculated, you must also pass the security token field `x-cos-security-token` when sending the request. The method for passing this field varies depending on how the signature is used:
1. When passing the signature through the standard HTTP Authorization header, you must also pass the security token field through the `x-cos-security-token` request header, for example:
Authorization: q-sign-algorithm=sha1&q-ak=************************************&q-sign-time=1557989753;1557996953&...&q-signature=****************************************
x-cos-security-token: ...
2. When passing the signature through HTTP request parameters, you must also pass the security token field through the `x-cos-security-token` request parameter, for example:
/exampleobject?q-sign-algorithm=sha1&q-ak=************************************&q-sign-time=1557989753%3B1557996953&...&q-signature=****************************************&x-cos-security-token=...
Note:
The preceding example uses ... to omit some specific signature and security token details.

Signature Example

Appendix

Pseudocode

KeyTime = [Now];[Expires]
SignKey = HMAC-SHA1([SecretKey], KeyTime)
HttpString = [HttpMethod]\\n[HttpURI]\\n[HttpParameters]\\n[HttpHeaders]\\n
StringToSign = sha1\\nKeyTime\\nSHA1(HttpString)\\n
Signature = HMAC-SHA1(SignKey, StringToSign)

Example Message Digest Algorithms

The following examples describe how to call HMAC-SHA1 in different languages.


Ajuda e Suporte

Esta página foi útil?

comentários