私は Alteryx という製品を使用しており、Alteryx 内から Dynamodb テーブルにアクセスできるように、Dynamodb クエリ API を利用する Alteryx マクロを作成しようとしています。残念ながら、Amazon SDK の 1 つを利用することはできないため、手動で / Alteryx 内で Amazon クエリ API 署名をコーディングする必要があります。
Amazon のドキュメントに含まれている Python Post の例を利用して、プロセスをガイドします。Python の例は、Python Post Exampleにあります。
例に示されている各タスクを完了しました。
- リクエスト変数の定義
- 正規リクエストを作成する
- 署名する文字列を作成する
- 署名を計算する
- 署名情報をリクエストに追加してリクエストを作成します。
最初は、次のエラーが発生していました。
InvalidSignatureException","message":"Signature·expired:·20150704T101118Z·is·now·earlier·than·20150704T135625Z·(20150704T141125Z·-·15·min.)
私のコンピュータの時刻は正確で、要求に含まれる 101118Z の時刻は実際には正確でしたが、エラー メッセージは、署名が 4 時間前に期限切れになったことを示していました。このエラーに対する私の回避策は、日付/時刻変数に 4 時間を追加することでした。これで問題が解決したようです。
質問 1 . このエラーの原因を知っている人はいますか?また、日付/時刻変数に 4 時間を追加せずに修正する方法はありますか? これにより、署名 API の署名と要求プロセスがさらに複雑になる可能性があります。
日付/時刻の回避策を適用した後、新しいエラー メッセージが表示されました。
InvalidSignatureException","message":"The·request·signature·we·calculated·does·not·match·the·signature·you·provided.·Check·your·AWS·Secret·Access·Key·and·signing·method.·Consult·the·service·documentation·for·details.\n\nThe·Canonical·String·for·this·request·should·have·been\n'POST\n/\n\ncontent_type:\nhost:dynamodb.us-east-1.amazonaws.com\nx-amz-date:20150704T141834Z\nx-amz-target:DynamoDB_20120810.CreateTable\n\ncontent_type;host;x-amz-date;x-amz-target\n09a8bcdeea1d20631f887235820bbff0a614679080a2e74a89ceb1a1bcc71b44'\n\nThe·String-to-Sign·should·have·been\n'AWS4-HMAC-SHA256\n20150704T141834Z\n20150704/us-east-1/dynamodb/aws4_request\nec549e12e44faf7ee750e19b570eaf2389f82e722ae2978b535df6fd6f3df129'\n"}
次に、Canonical Request とエラー メッセージで提供されたものを比較しました。これは私が見つけたものです：
- 要求は、1 つの例外を除いて同一でした。エラー メッセージに示されている正規のリクエストには content-type: ヘッダーが含まれていましたが、関連するコンテンツ タイプの値が除外されていました。
- 私の正規のリクエストには、content-type ヘッダーと値の両方が含まれていました。
- 正規のリクエストの最後にあるリクエスト パラメータのハッシュは、他のすべてのものと完全に一致しました。
正規のリクエストはプロセスの次のステップへの入力であるため、これは重要です。署名する文字列を作成するには、正規リクエストの sha256 ハッシュ ダイジェストを計算する必要があります。この問題に対して、次の 2 つの代替アプローチ/回避策を試しました。
- 最初に、導出した正規のリクエスト (content-type 値を含む) を使用して、署名する文字列を計算しました。この場合、最後の要素である正規リクエストのハッシュを除いて、すべてがエラー メッセージ String To Sign と一致しました。
- 私の次のアプローチは、コンテンツ タイプの値を除外した正規のリクエストを計算することでした。したがって、エラー メッセージに含まれる正規のリクエストと正確に一致しました。このシナリオでは、派生した署名する文字列は、正規のリクエストのハッシュを除いて完全に一致しました。
質問 2 : このエラーに遭遇した人はいますか? 原因を知っていますか、および/または回避策がありますか。
質問 3 に対処できるようになったら、4 番目のタスクを正常に完了して、署名を計算し、API リクエストを正常に作成できるようになることを願っています。
質問 3 : このプロセスの他の落とし穴を知っている人、または追加の提案や洞察を持っている人はいますか?