I'm using a product called Alteryx and I'm trying to write an Alteryx macro that utilizes the Dynamodb query API so that I can access my Dynamodb tables from within Alteryx. Unfortunately, I'm precluded from utilizing one of the Amazon SDK so have to code the Amazon query api signing manually / within Alteryx.
I am utilizing a Python Post example that is included in the Amazon documentation to guide me through the process. The Python example can be found here: Python Post Example.
I have completed each of the tasks laid out in the example:
- Define Request Variables
- Create a Canonical Request
- Create the string to sign
- Calculate the signature
- Add signing information to request and make request.
Initially I was getting the following error:
InvalidSignatureException","message":"Signature·expired:·20150704T101118Z·is·now·earlier·than·20150704T135625Z·(20150704T141125Z·-·15·min.)
Although the time on my computer is correct and the time of: 101118Z included in my request was actually correct, the error message was telling me that the signature had expired four hours ago. My work around for this error was to add 4 hours to my date/time variable(s) and this seemed to do the trick.
QUESTION 1. Is anyone familiar with what causes this error and is there a way to fix it without adding 4 hours to my date/time variable. Could this cause additional complications in the signing API signing and request processes.
After applying my date/time workaround, I was rewarded with a new error message:
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"}
So next I compared my Canonical Request to the one provided in the error message. This is what I found:
- The request were identical with one exception. The canonical request provided in the error message had the content-type: header but excluded the related content type value.
- My canonical request included both the content-type header and value.
- The hash of request parameters at the end of the canonical request matched perfectly along with everything else.
This is important because the canonical request is an input for the next step of the process. You have to calculate the sha256 hash digest of the canonical request to create the String To Sign. I've tried two alternative approaches/workarounds for this issues:
- First I used the canonical request I derived (including the content-type value) to calculate the string to sign. In this case everything matched the error messages String To Sign, except the last element: the hash of the canonical request.
- My next approach was to calculate a canonical request that excluded the content-type value and therefore matched the canonical request included in the error message exactly. In this scenario, the derived String To Sign matched perfectly except for the hash of the canonical request.
QUESTION 2: Has anyone come across this error; do you know the cause and/or do you have a workaround.
My hope is once I'm able to address Question 3, I will be able to successfully complete the 4th task, calculating the signature and successfully make an api request.
QUESTION 3: Is anyone aware of any other gotchas in this process or have any additional suggestions or insights.
Aucun commentaire:
Enregistrer un commentaire