If I send a request to my Lambda function with OAC/AWS_IAM enabled through CloudFront, most requests go through fine. I even added a Lambda@Edge function to handle signing POST/PUT requests with a body (as per this question).
However, if I hit a URL with a + in the URL, I always get a 403 error:
{"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."}
I have tried to make my Lambda@Edge function do all the signing (ditching the Cloudfront OAC) and have experimented with changing the URL encoding of the + (both to %2b and %20), but have been unsuccessful in getting a valid signature. In fact, some of those changes caused some URLs with query strings to also fail (e.g., /login?redirect=%2Fadmin%2F). At the moment, I've had to disable AWS_IAM on my Lambda Function URL to prevent the issue from occurring.
Is there a way to see what signature the Lambda function is expecting? I'm using largely this example for my Lambda@Edge function (minus the // remove the "behaviour" path from the uri to send to Lambda part since it is not relevant to my configuration).
My latest iteration only adds the x-amz-content-sha256 header (as described in the previously referenced question), and has the OAC enabled which seems to not alter the results. My assumption is that the OAC process is taking care of adding the rest of the headers after the Lambda@Edge function runs, and automatically picks up the updated header.
Right now, I assume there is a bug somewhere in one of the two places' handling URL encoding. Note that I've also tried using @smithy/signature-v4 and @smithy/protocol-http vs. @aws-sdk packages (and turning off the OAC on the origin) thinking said bug may have been resolved in a newer version, but I saw the same results.
Thoughts?
AWS OFFICIALUpdated 2 years ago
