Questions tagged with Amazon API Gateway

Content language: English

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Contact form for sending mail from AWS SES using AWS API Gateway

I am trying to create a serverless contact form in S3 that calls AWS API Gateway that then interacts with SES to send an email to a "contact us" email recipient. I am following the tutorial at https://levelup.gitconnected.com/creating-a-serverless-contact-form-on-aws-ff339ad1fa60 and am stuck at the part where I've created the API and am trying to test it with a JSON payload. The problem is the API test behaves as expected and returns a successful http 200 BUT it seems SES is returning an error that looks like -> ``` {"Error":{"Code":"SignatureDoesNotMatch","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.","Type":"Sender"},"RequestId":"1559f1b5-7000-4fe5-9d70-38b729adba46"} ``` Here is the entire execution stack from the API test in the AWS API configuration area -> ``` Execution log for request a18a0aa1-fa42-4bc8-a3c0-c6754716398f Fri Dec 02 20:19:12 UTC 2022 : Starting execution for request: a18a0aa1-fa42-4bc8-a3c0-c6754716398f Fri Dec 02 20:19:12 UTC 2022 : HTTP Method: POST, Resource Path: / Fri Dec 02 20:19:12 UTC 2022 : Method request path: {} Fri Dec 02 20:19:12 UTC 2022 : Method request query string: {} Fri Dec 02 20:19:12 UTC 2022 : Method request headers: {} Fri Dec 02 20:19:12 UTC 2022 : Method request body before transformations: { "name": "Test Name", "email": "test@test.com", "phone": "123-456-7890", "message": "This is a test message!" } Fri Dec 02 20:19:12 UTC 2022 : Endpoint request URI: https://email.us-east-1.amazonaws.com/SendEmailToWhomeverILike Fri Dec 02 20:19:12 UTC 2022 : Endpoint request headers: {Authorization=************************************************************************************************************************************************************************************************************************************************************************098c83, X-Amz-Date=20221202T201912Z, x-amzn-apigateway-api-id=1j6iefoiqj, Accept=application/json, User-Agent=AmazonAPIGateway_1j6iefoiqj, X-Amz-Security-Token=IQoJb3JpZ2luX2VjEJX//////////wEaCXVzLWVhc3QtMSJHMEUCIAVdXRcxBZlgf9mN9jqp6OxEtITF/KMl+MzbXyb89NZrAiEAzSxr6P0cIMDwGDkkXOYr1C2KINbRKN2X0zozBMh7fjIq7gIIrf//////////ARADGgwzMzc2MzIxMzUyNDQiDHpwxD6RfZw5uGjCHirCAse0l62z8auypaCu5K+bUgeCqsXqtE7bjBhct1ZG0WK5q5gw3DRKGLPmqPc9nFZ1pbeRUCw5LvuuI+6jQKs2CCJisZlgrGjSD/m1akgPkVsR1FtCNj6z7GEURaTg6r3aqz2KXyrHVft4cex+BoSOeMUMBBXWOKJirppkK8KGz4yNNPYFJ1BPLWQJcWOb6rPi/87pPoey0E3PiwLf1SXTVzkc/S/I/tpLzV7fARx4vheXC7c+SmAHyg/Zm318As5OBCqGBPXKpK0UT/7z4r9/vqDRzCsXXe0FCGJjOyMuM5y9k5bnsT5sRjpenX1DOkUopLoEsc2xTjunfEXKGmfn+M96I+Z3JbrnGMz [TRUNCATED] Fri Dec 02 20:19:12 UTC 2022 : Endpoint request body after transformations: Action=SendEmail&Message.Body.Text.Data=%0AName%3A+%22Test+Name%22%0AEmail%3A+%22test%40test.com%22%0APhone%3A+%22123-456-7890%22%0AMessage%3A+%22This+is+a+test+message%21%22&Message.Subject.Data=Contact+form+submission&Destination.ToAddresses.member.1=DudeDudely%40hotmail.com&Source=no_reply_contact_form_submission%40ThatBigTLD.com Fri Dec 02 20:19:12 UTC 2022 : Sending request to https://email.us-east-1.amazonaws.com/SendEmailToWhomeverILike Fri Dec 02 20:19:12 UTC 2022 : Received response. Status: 403, Integration latency: 21 ms Fri Dec 02 20:19:12 UTC 2022 : Endpoint response headers: {Date=Fri, 02 Dec 2022 20:19:12 GMT, Content-Type=application/json, Content-Length=300, Connection=keep-alive, x-amzn-RequestId=1559f1b5-7000-4fe5-9d70-38b729adba46} Fri Dec 02 20:19:12 UTC 2022 : Endpoint response body before transformations: {"Error":{"Code":"SignatureDoesNotMatch","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.","Type":"Sender"},"RequestId":"1559f1b5-7000-4fe5-9d70-38b729adba46"} Fri Dec 02 20:19:12 UTC 2022 : Method response body after transformations: {"Error":{"Code":"SignatureDoesNotMatch","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.","Type":"Sender"},"RequestId":"1559f1b5-7000-4fe5-9d70-38b729adba46"} Fri Dec 02 20:19:12 UTC 2022 : Method response headers: {X-Amzn-Trace-Id=Root=1-638a5dc0-85f935e6291eab49e7dbe023, Content-Type=application/json} Fri Dec 02 20:19:12 UTC 2022 : Successfully completed execution Fri Dec 02 20:19:12 UTC 2022 : Method completed with status: 200 ``` I have also tested this in Postman and I get the same results. The JSON payload I used in the test looks like -> ``` { "name": "Test Name", "email": "test@test.com", "phone": "123-456-7890", "message": "This is a test message!" } ``` I have an IAM role associated with this api that looks like ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "Custom", "Effect": "Allow", "Action": [ "ses:SendEmail" ], "Resource": "*" } ] } ```` This IAM role's ARN is referenced in the Integration Request section as Execution role arn:aws:iam::<ABigNumberImNotGoingToShowYou>:role/ApiGatewaySes My main question is ....... do I also need to send some other type of authentication token? If so where would I configure that information?
1
answers
0
votes
22
views
profile picture
asked a day ago

How to know if my Lambda Authorizer for API Gateway is caching results?

I have a Lambda Authorizer for an API Gateway API with one resource and three methods - PUT / GET / DELETE. Each method uses the same Lambda Authorizer, the TOKEN kind, to verify a JWT from Cognito. An IAM policy is returned by the Lambda which allows PUT / GET / DELETE actions on the resource. The authorization and policy work fine -- I just don't know if the result is being cached by API Gateway. When I look at the API Gateway execution logs, every request seems to be calling the Lambda Authorizer. Every API Gateway execution log has a line like this: ``` Sending request to https://lambda.us-east-1.amazonaws.com/2015-03-31/functions/arn:aws:lambda:us-east-1:123456789012:function:MY_LAMBDA_FUNCTION:prod/invocations ``` **Does this invocation of the Lambda function mean that the Lambda Authorizer is not caching properly?** After the "Sending request" log line, there's a line like "Authorizer result body before parsing" and then this line: ``` Using valid authorizer policy for principal: *****user ``` **Does this statement indicate that the Lambda Authorizer using a cached policy?** The strange thing is...when I check the Lambda logs, the execution times vary wildly, almost as if the Lambda itself is caching the result...but I think the caching happens on the API Gateway side? What's going on here? Sample of Lambda duration times: 529ms, 10ms, 217ms, 213ms, 8ms, 2ms
0
answers
0
votes
26
views
profile picture
asked 5 days ago

mutual TLS authentication for Amazon API Gateway - With my existing public key infrastructure (PKI) standard.

Hello Team, I am trying to enable mTLS for Amazon API Gateway for my endpoint, and I have my existing public key (PKI) for my domain (.crt & .key)..While using to upload my existing root CA public key in S3 bucket, I am getting some error like "API Gateway couldn’t build a unique path from the given certificate to a root certificate". I am following the setup using this link, Ref : https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-api-gateway/ Note : I am not using the openssl to generate the RootCA.pem & RootCA.key. Step 1: (SKIP) Create the private certificate authority (CA) private and public keys: openssl genrsa -out RootCA.key 4096 openssl req -new -x509 -days 3650 -key RootCA.key -out RootCA.pem Step 2: Create client certificate private key and certificate signing request (CSR): openssl genrsa -out my_client.key 2048 openssl req -new -key my_client.key -out my_client.csr Step 3: Sign the newly created client cert by using your certificate authority you previously created: openssl x509 -req -in my_client.csr -CA RootCA.pem -CAkey RootCA.key -set_serial 01 -out my_client.pem -days 3650 -sha256 Step 4: I have a minimum of five files in my directory RootCA.key (root CA private key) RootCA.pem (root CA public key) my_client.csr (client certificate signing request) my_client.key (client certificate private key) my_client.pem (client certificate public key) Step 5: Prepare a PEM-encoded trust store file for all certificate authority public keys you want to use with mutual TLS: cp RootCA.pem truststore.pem Step 6: Upload the trust store file to an Amazon S3 bucket in the same AWS account as our API Gateway API. aws s3 mb s3://your-name-ca-truststore --region us-east-1 #creates a new S3 bucket – skip if using existing bucket aws s3api put-bucket-versioning --bucket your-name-ca-truststore --versioning-configuration Status=Enabled #enables versioning on S3 bucket aws s3 cp truststore.pem s3://your-name-ca-truststore/truststore.pem #uploads object to S3 bucket Step 7: Enabling mutual TLS on a custom domain name I have in AWS API gateway console, While I upload my existing root CA public key in S3 bucket, I am getting some error like Error : "API Gateway couldn’t build a unique path from the given certificate to a root certificate". Error : "There is an invalid certificate in your truststore bundle Mutual TLS is still enabled, but some clients might not be able to access your API. Upload a new truststore bundle version to S3, and then update your domain name to use the new version."
1
answers
0
votes
19
views
asked 6 days ago