Webで2日間以上検索し、おそらくオンラインで文書化されたシナリオと回避策のほとんどを調べましたが、これまでのところ何もうまくいきませんでした。
PHP 5.3で実行されているPHP V2.8.7のAWS SDKを使用しています。次のコードを使用してS3バケットに接続しようとしています。
// Create a `Aws` object using a configuration file
$aws = Aws::factory('config.php');
// Get the client from the service locator by namespace
$s3Client = $aws->get('s3');
$bucket = "xxx";
$keyname = "xxx";
try {
$result = $s3Client->putObject(array(
'Bucket' => $bucket,
'Key' => $keyname,
'Body' => 'Hello World!'
));
$file_error = false;
} catch (Exception $e) {
$file_error = true;
echo $e->getMessage();
die();
}
//
私のconfig.phpファイルは次のとおりです。
<?php
return array(
// Bootstrap the configuration file with AWS specific features
'includes' => array('_aws'),
'services' => array(
// All AWS clients extend from 'default_settings'. Here we are
// overriding 'default_settings' with our default credentials and
// providing a default region setting.
'default_settings' => array(
'params' => array(
'credentials' => array(
'key' => 'key',
'secret' => 'secret'
)
)
)
)
);
次のエラーが発生しています。
計算したリクエストの署名は、指定した署名と一致しません。キーと署名方法を確認してください。
すでに20回以上アクセスキーとシークレットを確認し、新しいものを生成し、情報を渡すためにさまざまな方法(プロファイルとコード内の資格情報を含む)を使用しましたが、現時点では何も機能していません。
2日間のデバッグの後、私はついに問題を発見しました...
私がオブジェクトに割り当てていたキーは、ピリオド、つまり..\images\ABC.jpg
で始まり、これによりエラーが発生しました。
APIがもっと意味のある適切なエラーメッセージを提供することを望みます、悲しいかな、これが他の誰かに役立つことを願っています!
間違った資格情報でこのエラーが発生します。元々貼り付けたときに目に見えないキャラクターがあったと思います。
いくつかのUTF8文字を含むオブジェクトをコピーしようとすると、同じ問題が発生しました。以下はJSの例です。
var s3 = new AWS.S3();
s3.copyObject({
Bucket: 'somebucket',
CopySource: 'path/to/Weird_file_name_ðÓpíu.jpg',
Key: 'destination/key.jpg',
ACL: 'authenticated-read'
}, cb);
CopySourceをencodeURIComponent()
でエンコードすることで解決しました
他の言及された解決策のどれもあなたのために働かない場合、使用してみてください
aws configure
このコマンド は、キー、リージョン、および出力形式を要求する一連のオプションを開きます。
お役に立てれば!
実際にJavaで同じエラーが発生していました。デバッグに4時間を費やした後、S3ファイルのキャッシュコントロールに座っている間にスペースがあったため、S3オブジェクトのメタデータに問題があることがわかりました。 1.6。*バージョンでは許可されていましたが、1.11。*では許可されていないため、署名の不一致エラーがスローされていました
以前のバージョンのaws-php-sdkでは、S3Client::factory()
メソッドが非推奨になる前に、ファイルパスの一部、またはKey
を呼び出すことが許可されていました- S3Client->putObject()
parameters 、バケットパラメーター。 v2 SDKを使用して、実稼働で使用するファイルマネージャーがありました。ファクトリメソッドはまだ機能しているため、~3.70.0
に更新した後、このモジュールを再検討しませんでした。今日、私はこのエラーを受信し始めた理由をデバッグするのに2時間の大半を費やしました。
$s3Client = new S3Client([
'profile' => 'default',
'region' => 'us-east-1',
'version' => '2006-03-01'
]);
$result = $s3Client->putObject([
'Bucket' => 'awesomecatpictures/catsinhats',
'Key' => 'whitecats/white_cat_in_hat1.png',
'SourceFile' => '/tmp/asdf1234'
]);
次のように、バケット/キーパスのcatsinhats
部分をKey
パラメーターに移動する必要がありました。
$s3Client = new S3Client([
'profile' => 'default',
'region' => 'us-east-1',
'version' => '2006-03-01'
]);
$result = $s3Client->putObject([
'Bucket' => 'awesomecatpictures',
'Key' => 'catsinhats/whitecats/white_cat_in_hat1.png',
'SourceFile' => '/tmp/asdf1234'
]);
私が起こっていると信じていることは、Bucket
の名前がURLエンコードされているということです。 SDKから受け取った正確なメッセージをさらに調べたところ、次のことがわかりました。
https://s3.amazonaws.com/awesomecatpictures%2Fcatsinhats/whitecats/white_cat_in_hat1.png
でPutObject
の実行エラー
AWS HTTPエラー:クライアントエラー:PUT https://s3.amazonaws.com/awesomecatpictures%2Fcatsinhats/whitecats/white_cat_in_hat1.png
は403 Forbidden
になりました
これは、Bucket
パラメーターに提供された/
がurlencode()
を経由し、現在は%2F
であることを示しています。
署名の仕組みはかなり複雑ですが、問題はバケットに要約され、キーは暗号化された署名の生成に使用されます。呼び出し元のクライアントとAWSの両方で完全に一致しない場合、リクエストは403で拒否されます。エラーメッセージは実際に問題を指摘しています。
計算したリクエストの署名は、指定した署名と一致しません。 キーと署名方法を確認してください。
したがって、私のKey
が間違っていたため、私のBucket
は間違っていました。
AWS SDKを使用してReact Nativeを使用してS3に画像をアップロードすることを経験しました。 ContentEncoding
パラメーターが原因であることが判明しました。
そのパラメーターを削除すると、問題が「修正」されました。
私の場合、S3のURLをコンポーネントに解析しました。
例えば:
Url: s3://bucket-name/path/to/file
に解析されました:
Bucket: bucket-name
Path: /path/to/file
先頭に「/」を含むパス部分があると、要求は失敗しました。
同様のエラーが発生しましたが、私にとっては、IAMユーザーを再利用して2つの異なるElastic Beanstalk環境でS3を操作したことが原因のようです。 環境ごとに同一の許可されたIAMユーザーを作成するで症状を処理し、エラーを解消しました。
私はaxiosを使用し、デフォルトではヘッダーを送信します
content-type: application/x-www-form-urlencoded
だから私は送信するように変更します:
content-type: application/octet-stream
また、このContent-TypeをAWS署名に追加する必要がありました
const params = {
Bucket: bucket,
Key: key,
Expires: expires,
ContentType = 'application/octet-stream'
}
const s3 = new AWS.S3()
s3.getSignedUrl('putObject', params)
同じ問題がありました。デフォルトのメソッドであるPUTは事前署名済みURLを定義するように設定されていましたが、GETを実行しようとしました。エラーはメソッドの不一致が原因でした。
Debianストレッチで利用可能な最新のawscli
バージョン、つまりバージョン1.11.13を使用しているときに、AWS以外のS3エンドポイントを使用したDockerイメージでこれに遭遇しました。
CLIバージョン1.16.84にアップグレードすると、問題が解決しました。
次の代わりに、Debianストレッチイメージに基づいたDockerfileでCLIの最新バージョンをインストールするには
RUN apt-get update
RUN apt-get install -y awscli
RUN aws --version
つかいます:
RUN apt-get update
RUN apt-get install -y python-pip
RUN pip install awscli
RUN aws --version
ブラウザで出力されたURLをテストしようとしているときにこの問題に誰かが来たかどうかはわかりませんが、Postman
を使用して、RAW
タブから生成されたAWSのURLをコピーしようバックスラッシュをエスケープすると、上記のエラーが発生します。
Pretty
タブを使用してURLをコピーして貼り付け、実際に機能するかどうかを確認します。
最近この問題に遭遇し、このソリューションで問題を解決しました。 URLを介して実際にデータを取得するかどうかを確認するためのテスト目的です。
この回答は、ダウンロード、AWSからの一時リンクの生成、または一般的にAWSから使用するURLの生成を試みる人への参照です。
私の場合(Python)、ファイルにこれらの2行のコードがあり、古いコードから継承されたため失敗しました
http.client.HTTPConnection._http_vsn = 10 http.client.HTTPConnection._http_vsn_str = 'HTTP/1.0'
Java SDKを介してCloudSearchにドキュメントをアップロードしているときにこのエラーが発生しました。この問題は、アップロードするドキュメントの特殊文字が原因でした。エラー「計算したリクエストの署名は、指定した署名と一致しません。AWSシークレットアクセスキーと署名方法を確認してください。」非常に誤解を招く。
設定しなければならなかった
Aws.config.update({
credentials: Aws::Credentials.new(access_key_id, secret_access_key)
})
前にRuby aws sdk v2を使用しました(他の言語でもおそらくこれに似たものがあります)
環境変数を設定することでこの問題を解決できました。
export AWS_ACCESS_KEY=
export AWS_SECRET_ACCESS_KEY=
IntelliJ + py.testでは、[Run] > [Edit Configurations] > [Configuration] > [Environment] > [Environment variables]
で環境変数を設定します
私の場合の問題は、Amplifyの設定に使用されるAPIゲートウェイURLで、最後に余分なスラッシュがありました...
クエリされたURLはhttps://....amazonaws.com/myapi//myendpoint
のように見えました。 confの余分なスラッシュを削除し、機能しました。
私の人生で最も明確なエラーメッセージではありません。
私の場合、バケット名が間違っていて、キーの最初の部分(bucketxxx/keyxxx)が含まれていました。署名には何も問題はありませんでした。
Nodejsでも同じエラーが発生しました。しかし、s3コンストラクターにsignatureVersion
を追加すると助けになりました。
const s3 = new AWS.S3({
apiVersion: '2006-03-01',
signatureVersion: 'v4',
});
私の場合、s3request.promise().then()
incorrecltyを呼び出していたため、1回の呼び出しだけでリクエストが2回実行されました。
つまり、6つのオブジェクトを繰り返し処理していましたが、12のリクエストが行われました(コンソールにログインするか、ブラウザーでネットワークをデバッグすることで確認できます)
2番目の不要なリクエストのタイムスタンプが、この問題を引き起こした最初のリクエストの署名と一致しなかったためです。
別の考えられる問題は、メタ値に非US-ASCII文字が含まれていることです。私にとっては、putRequestに値を追加するときに値をUrlEncodeするのに役立ちました:
request.Metadata.Add(AmzMetaPrefix + "artist", HttpUtility.UrlEncode(song.Artist));
request.Metadata.Add(AmzMetaPrefix + "title", HttpUtility.UrlEncode(song.Title));