この記事では、PHP を使用して COS インターフェースを作成するために必要なリクエスト署名を主に紹介します。公式ドキュメントに記載されている例と比較して、アルゴリズムが正しいかどうかを確認してください。
COS とリクエストとは何ですか。署名
COS は、Tencent Cloud Object Storage の略語で、サードパーティが COS 関連のインターフェイスを呼び出すときにオンデマンドで提供する必要がある、特定のアルゴリズムによって作成された一連の文字列情報です。 party.Identity、通信する双方の当事者の識別を提供します。有効な署名のみ COS がサービスを提供します
目標
PHP を使用して、COS インターフェイスに必要なリクエスト署名を作成し、公式ドキュメントに記載されている例と比較します。アルゴリズムの正しさを検証する
リクエストの署名を理解する
まずは公式文書に記載されているリクエストの署名を見てみましょう
q-sign-algorithm=sha1&q-ak=[SecretID]&q-sign-time=[SignTime]&q-key-time=[KeyTime]&q-header-list=[SignedHeaderList]&q-url-param-list=[SignedParameterList]&q-signature=[Signature]
リクエストの署名の特徴をまとめると
は文字列です文字列の
key=valueキーと値のペア形式、keyは固定値です
key=valueのペアは7つあります
sha1もパラメータですが、正式リリース時点ではsha1 がサポートされているため、3 つの値を直接割り当てることができます
SignedHeaderList、SignedParameterList、および Signature を通じて生成する必要がある
キーと値のペアの詳細な説明については、公式ドキュメントを参照してください。アルゴリズム。
1つずつ分割する
署名をリクエストするには、以下でそれぞれの
q-sign-algorithm
署名アルゴリズムを1つずつ説明していきます。そのため、単に与えるだけです。値を直接取得します
q-ak
アカウント ID、つまりユーザーの SecretId は、コンソールの Cloud API Key ページで取得できます
q-sign-time
現在の署名、Unix タイムスタンプ形式、英語の半角セミコロン、分割、形式は次のとおりです 1480932292;1481012298
q-key-time
q-sign-time
q-header-list
Personalと同じ値HTTP リクエスト ヘッダーで構成されており、リクエスト ヘッダーのすべてまたは一部を取得し、key:value 形式を使用します。 リクエスト アイテムのキー部分を取り出し、小文字に変換し、辞書に従って複数のキーをソートし、それらを接続します; の文字を使用し、最後に文字列を形成します
たとえば、元のリクエストヘッダーには次の 2 つがあります:
Host:bucket1-1254000000.cos.ap-beijing.myqcloud.com
Content-Type:image/jpeg
key は Host と Content-Type、操作後、出力 content-type;host
q-url-param- list
個人的な理解ですが、HTTPリクエストパラメータで構成されており、リクエストパラメータの全部または一部を取り出し、key=valueの形式でリクエストパラメータのキー部分を取り出し、それを小文字に変換することで複数のキーをソートしています。辞書を文字 ; で結び、最終的に文字列に形成します
たとえば、元の HTTP リクエストは次のようになります:
GET /?prefix=abc&max-keys=20
key は prefix と max-keys であり、操作後に max-keys が出力されます。リクエストにパラメーターがない場合、たとえば put、post、これは空です
q-signature
HTTP コンテンツに基づいて署名を計算します。アルゴリズムは COS によって提供され、必要に応じて値を指定するだけです
公式の例と参考結果
ロジックを書き始める前に見てみましょう
開発したロジックと結果を比較できるように、公式の例で示されている参考値と計算結果を見てみましょう。
HTTP 元のリクエストは、署名を計算する前、または署名が必要ない場合の HTTP リクエストとして理解することもできます:
PUT /testfile2 HTTP/1.1
Host: bucket1-1254000000.cos.ap-beijing.myqcloud.com
x-cos-content-sha1: 7b502c3a1f48c8609ae212cdfb639dee39673f5e
x-cos-storage-class: standard
Hello world
署名を計算した後に取得する必要がある HTTP リクエスト:
PUT /testfile2 HTTP/1.1
Host: bucket1-1254000000.cos.ap-beijing.myqcloud.com
x-cos-content-sha1: 7b502c3a1f48c8609ae212cdfb639dee39673f5e
x-cos-storage-class: standard
Authorization: q-sign-algorithm=sha1&q-ak=AKIDQjz3ltompVjBni5LitkWHFlFpwkn9U5q&> q-sign-time=1417773892;1417853898&q-key-time=1417773892;1417853898&q-header-list=host;x-cos-content-sha1;x-cos-storage-class&q-url-param-list=&q-signature=14e6ebd7955b0c6da532151bf97045e2c5a64e10
Hello world
結論: アルゴリズムは、取得できれば正しいです認可後の文字列を取得します
準備
（公式に提供されている）ユーザー情報とHTTP情報を見てみましょう:
SecretId: AKIDQjz3ltompVjBni5LitkWHFlFpwkn9U5q
SecretKey: BQYIM75 p8x0iWVFSIgqEKwFprpRSVHlz
署名有効開始時間: 141 7773892
署名の有効な終了時刻: 1417853898
HTTP 元のリクエストヘッダー: 前のセクションの例に従っていない 3 つの内容を持つ HTTP 元のリクエストを取得することは困難です: Host、x-cos- content-sha1とx-cos-storage-class
HTTPリクエストパラメータ: PUTリクエストですよね？次の表に示すように、結果を取得することは難しくありません。 sha1
q-ak
AKIDQjz3ltompVjBni5LitkWHFlFpwkn9U5qSecretId フィールド |
| q-sign-time | 1417 773892;1417853898
2014/12/5 18:04 :52 に2014/12/6 16:18:18
| q-key-time | 1417773892;1417853898 | 2014/12/5 18:04:52 から 2014/12/6 16:18:18
| | q-header-list | host; HTTPパラメータリストが空です |
Q-SIGNATURE | 14E6EBD7955B0C6DA532151BF97045E2C5A64E10 |
但 q-signature 怎么来的？
刚才说到，q-signature 也需要特定算法计算得来，下面就说明如何计算
计算请求签名
先看代码：
/**
* 计算签名
* secretId、secretKey 为必需参数，qSignStart、qSignEnd为调试需要，测试通过后应取消，改为方法内自动创建
*/
function get_authorization( $secretId, $secretKey, $qSignStart, $qSignEnd, $fileUri, $headers ){
/*
* 计算COS签名
* 2018-05-17
* author:cinlap <cash216@163>
* ref:https://cloud.tencent.com/document/product/436/7778
*/
$qSignTime = "$qSignStart;$qSignEnd"; //unix_timestamp;unix_timestamp
$qKeyTime = $qSignTime;
$header_list = get_q_header_list($headers);
//如果 Uri 中带有 ?的请求参数，该处应为数组排序后的字符串组合
$url_param_list = '';
//compute signature
$httpMethod = 'put';
$httpUri = $fileUri;
//与 q-url-param-list 相同
$httpParameters = $url_param_list;
//将自定义请求头分解为 & 连接的字符串
$headerString = get_http_header_string( $headers );
// 计算签名中的 signature 部分
$signTime = $qSignTime;
$signKey = hash_hmac('sha1', $signTime, $secretKey);
$httpString = "$httpMethod\n$httpUri\n$httpParameters\n$headerString\n";
$sha1edHttpString = sha1($httpString);
$stringToSign = "sha1\n$signTime\n$sha1edHttpString\n";
$signature = hash_hmac('sha1', $stringToSign, $signKey);
//组合结果
$authorization = "q-sign-algorithm=sha1&q-ak=$secretId&q-sign-time=$qSignTime&q-key-time=$qKeyTime&q-header-list=$header_list&q-url-param-list=$url_param_list&q-signature=$signature";
return $authorization;
}为了测试，该方法参数应该是多过需要了，前六个参数是已经给出的，是来自用户的，因此直接赋值即可得到下边字符串：
$authorization = "q-sign-algorithm=sha1&q-ak=$secretId&q-sign-time=$qSignTime&q-key-time=$qKeyTime...
$header_list 这个值要符合 q-header-list 规则因此需要计算，逻辑是上文已经描述，是从既定的请求项中抽出 key 组成有序字符串，代码如下：
/**
* 按COS要求对header_list内容进行转换
* 提取所有key
* 字典排序
* key转换为小写
* 多对key=value之间用连接符连接
*
*/
function get_q_header_list($headers){
if(!is_array($headers)){
return false;
}
try{
$tmpArray = array();
foreach( $headers as $key=>$value){
array_push($tmpArray, strtolower($key));
}
sort($tmpArray);
return implode(';', $tmpArray);
}
catch(Exception $error){
return false;
}
}$url-param-list 上面讲过，这个值是HTTP请求参数，对于 PUT 方法没有 ? 参数，自然值为空，所以代码中“偷懒”直接给了空字符串。
Signature 的计算和需要小心的地方
官方已经给出了完整的算法，PHP 甚至还有写好的代码，应该是很幸福了（但！由于看官方文档看的头晕还是踩了坑，随后一起说明），先看一下 signature 的“格式”：
SignKey = HMAC-SHA1(SecretKey,"[q-key-time]")
HttpString = [HttpMethod]\n[HttpURI]\n[HttpParameters]\n[HttpHeaders]\n
StringToSign = [q-sign-algorithm]\n[q-sign-time]\nSHA1-HASH(HttpString)\n
Signature = HMAC-SHA1(SignKey,StringToSign)
再看一下 Signature 的完整算法：
$signTime = $qSignTime;
$signKey = hash_hmac('sha1', $signTime, $secretKey);
$httpString = "$httpMethod\n$httpUri\n$httpParameters\n$headerString\n";
$sha1edHttpString = sha1($httpString);
$stringToSign = "sha1\n$signTime\n$sha1edHttpString\n";
$signature = hash_hmac('sha1', $stringToSign, $signKey);
$signTime：很简单，起止时间组成的字符串，从上文拿来直接用
$signKey：HMAC-SHA1 算法直接计算即可
$httpString：四个部分组成需要分开说
1、$httpMethod：HTTP请求方法，小写，比如 put、get
2、$httpUri：HTTP请求的URI部分，从“/”虚拟根开始，如 /testfile 说明在存储桶根目录下创建一个叫 testfile 的文件，/image/face1.jpg 说明在根目录/image目录下建立一个叫 face1.jpg 的文件，至于是不是图片文件，不管
3、$httpParameters：这是第一个需要小心的地方。由HTTP原始请求参数组成，即请求 URI 中 ? 后面的部分，本例调用的是 PUT Object 接口，因此为空。如果不为空，需要把请求参数每一项的 key 和 value 均转换小写，多对 key=value 按字典排序并以 & 相连接
4、$headerString：这是第二个需要小心的地方，由 HTTP 原始请求头组成，根据请求头，选择全部或部分请求头，把每项的key都转换为小写，把value都进行URLEncode转换，每项格式都改为key=value，然后按照key进行字典排序，最后把它们用连接符 & 组成字符串。这是我整理的逻辑，代码如下：
/**
* 按COS要求从数组中获取 Signature 中 [HttpString] 内容
* 标准格式 key=value&key=value&...
* 数组元素按键字典排序 *
* key转换为小写
* value进行UrlEncode转换
* 转换为key=value格式
* 多对key=value之间用连接符连接
*
*/
function get_http_header_string($headers){
if(!is_array($headers)){
return false;
}
try{
$tmpArray = array();
foreach($headers as $key => $value){
$tmpKey = strtolower($key);
$tmpArray[$tmpKey] = urlencode($value);
}
ksort($tmpArray);
$headerArray = array();
foreach( $tmpArray as $key => $value){
array_push($headerArray, "$key=$value");
}
return implode('&', $headerArray);
}
catch(Exception $error){
return false;
}
}为什么要小心？
HTTP原始请求头和请求参数用在了四个地方，分别是请求签名里的 q-header-list 和 Signature 里的 HttpHeaders——两者都用到了HTTP原始请求头；请求签名里的 q-url-param-list 和 Signature 里的 HttpParameters——两者都用到了HTTP请求参数。一定要保证HTTP请求头和请求参数所选用的数量和对象一致
相同：生成 q-header-list 的HTTP请求头数量和成员要和生成 HttpHeaders 的相同，生成 q-url-param-list 的HTTP请求参数数量和成员要和生成 HttpParameters 的相同
不同：q-header-list 和 q-url-param-list 只取 key 部分，HttpHeaders 和 HttpParameters 取 key 和 value 部分
输出结果和校验
至此，请求签名中7个值都有了，有的是来自用户信息，有的需要计算，需要计算的上面也给出了所有的计算方法和为什么如此计算的个人理解。最后只需要按照官方要求进行输出即可。看一下
以上がPHP は Tencent Cloud COS インターフェースに必要なリクエスト署名を生成しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
