1

したがって、私の iPhone アプリは写真を Amazon S3 に正常にアップロードします。最新 (ver 1.6.0) の Amazon AWS SDK for iOS で S3Uploader サンプル プロジェクトと同じコードを使用しました。問題は、断続的に SignatureDoesNotMatch エラーが発生することです (計算した要求署名が、提供された署名と一致しません。キーと署名方法を確認してください)。それにパターンはありません。現在、私のアプリは、didFailWithError: のデリゲート呼び出しで一定量の再試行を行うことで、このエラーを回避しています。

これまでのテストでは、ユーザーがエラーに気付かないように十分な再試行が行われていますが、署名が明らかに正しいときに署名キーのエラーが発生していることを知っていると、非常にイライラします。URL エンコーディング エラー (署名キーに + 記号が含まれている) であるかどうかはわかりませんが、iOS SDK を使用しているため、PUT URL がどのように処理されるかわかりません。

また、バケット名はすべて小文字で、ファイル名は数字と数文字のアルファベットのみであることを確認しました。また、さまざまな地域を試しましたが、すべて同じ結果になりました。つまり、SignatureDoesNotMatch エラーなしで PUT を成功させるには、0 回から 5 回の再試行が必要です。誰かに同様の問題がありましたか？どんな助けでも大歓迎です。読んでくれてありがとう。

4

2 に答える 2

3

有効な base64 がクエリ文字列で常に有効であるとは限らないため、生成後に署名をマッサージする必要がある場合があります。私が書いたいくつかのコードで次のコメントを見つけたので、私は昔々同じ問題に遭遇したに違いありません:

# the "+" is not url-safe, as it gets converted to a space somewhere along the line

# '+' => '%2B'

# while we're at it, we'll go ahead and convert the other non-safe-ish 
# characters even though the links seem to work without this step

# '/' => '%2F'
# '=' => '%3D'

私のコードは、これらの 3 文字の文字列検索と置換を行い、クエリ文字列を呼び出し元に返す前に、それらを URL エンコードされた同等のものに変更します。私が作業していた環境では、適切な URL エンコード ライブラリが利用できなかったので、検索/置換戦術を使用しました。これらは私のコードが生成できる唯一の 3 つの base64 文字であり、明らかに URL セーフではないため、先に進んで 3 つの可能性すべてを処理したようです。

于 2013-07-24T04:05:00.863 に答える