署名付きURLを使用してファイルをS3にPUT

これは確かに少し不可解ですが、私はそれをAWS SDK for Javaのバグだと考えています（以下を参照）-ただし、何よりもまず、次のcurlコマンドがファイルをアップロードします（もちろん、更新済みの署名済みURLを想定しています） ）：

curl -v -T mypicture.jpg https://mybucket.s3.amazonaws.com/myfilename?Expires=1334126943&AWSAccessKeyId=<accessKey>&Signature=<generatedSignature>

つまり、結果として（または）Content typeを生成するヘッダーを除外しましたが、これは明らかに望ましくありません。したがって、さらなる掘り起こしが必要でした。application/octet-streambinary/octet-stream

背景/分析

Amazon S3へのPUT（およびDELETEとHEAD）リクエストの事前署名付きURLは、原則として機能することがわかっており、このサイトの関連する質問で最も明白ではありません（たとえば、事前署名付きのs3へのアップロードとカールへの私の回答を参照）URL（403を取得））。

簡易化されたクエリ文字列要求認証の代替は、クエリ文字列要求認証方法を示す次の疑似文法を使用するように文書化されています。

StringToSign = HTTP-VERB + "\n" +
    Content-MD5 + "\n" +
    Content-Type + "\n" +
    Expires + "\n" +
    CanonicalizedAmzHeaders +
    CanonicalizedResource;    

これにはContent-Typeヘッダーが含まれますが、（すでに発見したように）いくつかの文書化されたケースではこれが欠けている部分です。たとえば、PUTリクエストを使用したGetPreSignedURLに対するAWSチームの応答を参照してください。追加すると、有効な署名済みURLが生成されます。

これは、AWS SDK for .NETを使用して簡単に実現できます。これは、まさにそれを行うための便利なメソッドGetPreSignedUrlRequest.WithContentTypeを提供します。

このリクエストのContentTypeプロパティを設定します。このプロパティのデフォルトは「binary / octet-stream」ですが、必要な場合はこのプロパティを設定できます。

したがって、次のように、それぞれのサンプル「署名済みURLを使用したオブジェクトのアップロード-AWS SDK for .NET」を拡張すると、コンテンツタイプが含まれた有効な署名済みURLが生成されます。これは、curlを介して（つまり、意図したとおりに）アップロードできます。

    // ...
    GetPreSignedUrlRequest request = new GetPreSignedUrlRequest();
    // ...
    request.WithContentType("image/jpg");
    // ...

次に、意味的に同一のサンプルを拡張し、事前署名済みURLを使用してオブジェクトをアップロードする-AWS SDK for Javaを同様の方法で拡張しますが、（すでに発見したように）これを実現する専用の方法はありません。これは便利なメソッドが欠けているだけかもしれませんが、最終的にはaddRequestParameter（）またはsetResponseHeaders（）を使用して実現できる可能性があります。例：

  // ...
  request.setExpiration( new Date( System.currentTimeMillis() + (120 * 60 * 1000) ));
  request.addRequestParameter("content-type", "image/jpg");
  return client.generatePresignedUrl( request ).toString();
  // ...

ただし、両方のメソッドのドキュメントは他の目的を示唆しており、実際には機能しません。つまり、どのコンテンツタイプがそのように設定されていても（もしあれば）常に同じ署名を生成します。

SDKをさらにデバッグすると、どちらも前述の疑似文法に従ってクエリ文字列認証を計算するための意味論的に類似したコアメソッドを提供していることがわかります。.NETのbuildSigningString（）およびJavaのmakeS3CanonicalString（）を参照してください。

しかし、すべての興味深いヘッダーをリストに追加し、それらをソートする Javaバージョンのそれぞれのコードは、「興味深い」がContent-MD5、Content-Type、Date、およびx-amz-として定義されているため、実際には決して実行されません。いかなるクラスにのみ利用可能である何とかこれらのヘッダを提供する方法であって、実際に存在しないDefaultRequestクラスないGeneratePresignedUrlRequestが保護方法を参照、順番に署名を計算するための入力として使用され、前者を初期化するために使用createRequestは（） 。

Javaは、ほぼ逆の組み合わせから自分の入力を構成する対興味深いことに/注目すべきは、二つの方法は、.NETでのクエリ文字列認証を計算するために、ヘッダ対パラメータのJavaのバグの原因にヒントができコールスタック、上のソースが、もちろん、それを解読するのは難しいかもしれません。つまり、内部アーキテクチャはもちろん大きく異なる可能性があります。

予備的な結論

これには2つの角度があります。

• AWS SDK for Javaには、コンテンツタイプを設定するための便利なメソッドが欠けています。これは比較的まれなことかもしれませんが、それでも他のAWS SDKで説明されている明らかなユースケース-AWS関連のバックエンドサービスで広く使用されていることを考えると、これは驚くべきことです。
• いずれにせよ、たとえば.NETバージョンと比較して、クエリ文字列リクエスト認証の実装方法には多少の問題があるようです。これもコア機能であるため、これは驚くべきことですが、これはまだS3モデル内にあります/名前空間、したがって、上記のそれぞれのユースケースでのみ必要になる場合があります。

結論として、これを解決するための唯一の合理的な方法は更新されたSDKであるため、バグレポートが必要です。明らかに、このSDKの機能を複製または拡張して、この特別なケースを個別に説明できます（理想的には、送信できるようにする方法で）aws-sdk-for-javaプロジェクトのプルリクエスト）ですが、互換性と保守性のある方法でこれを正しく行うことは少し難しいように思われるため、SDKメンテナー自身が行うのが最善です。