My API gateway inkoves a lambda function by passing the event with request parameters.
I'm trying to add few more request params to the existing api gateway through terraform and applied the changes successfully, but by inkoving the api with all the request parameters (existing and newly added), the event object that passed to the invoked lambda doesn't have the newly added request params.
Do I need to delete the entire api gateway and re-create with newly added params?
It got resolved by redeploying API gateway.
Related
I'm creating an Axios call to an API hosted on APIGateway with no Authorizer etc. I'm able to access the lambda via a direct postman request and also on the service lambda when it's ran in offline mode, such as:
https://localhost:3000/my/api
However when i run it on the dev stage:
12345.execute-api.eu-west-1.amazonaws.com/my/api
I'm getting a a 403: Forbidden error thrown back.
I've seen comments from other posts where they needed to append the staging environment at the end of the request but this isn't the case in this instance as it's just creating a default endpoint and all other lambdas within this service can be hit when ran on dev, it's just this one that makes a call to another APIGateway API.
The calling API is behind an authorizer with a wildcard policy so should allow all traffic and I'd like to reiterate, it works on both localhost and a direct call to the invoked api.
I'm wondering if it's something to do with the policies attached to it but I've set them all to be wildcarded as well so it should allow everything.
Any ideas would be really helpful, I've been wracking my brains over this all day.
Edit: The authorizer has no policy denying access to the API, same as the resource policy.
There are two common reasons why an API Gateway REST API with a Lambda authorizer returns a 403 error:
The Lambda authorizer function returns an AWS Identity and Access Management (IAM) policy document that explicitly denies access to the caller.
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-lambda-authorizer-output.html
The second reason will be, The API has an attached resource policy that explicitly denies access to the caller.
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html
If both are in place, please update the question with those details.
I am brand new to AWS API Gateway/AWS Lambda/AWS Amplify. I have a React Native application that I am trying to use AWS Amplify to make an API call and issue a PUT request, which would then cause the API Gateway to invoke my AWS Lambda function. When I create the AWS Amplify API endpoint, I don't see a command line option to define a PUT method. The default is "Any", which works, but I would like to specify a PUT method specifically. When I add in a PUT method manually on the API Gateway website and then call it from my React Native front end, I get...
Error: Request failed with status code 500
Looking at the API Gateway responses, this is due to either an "Authorizer Configuration Error" or an "Authorizer Failure", so I am assuming the problem is not with my front end code but with the configuration of "authorizers" on the API Gateway. What are authorizers? How do they relate to making an API call? And what steps can I take to troubleshoot what the problem might be?
You can use a lambda, a Cognito User Pool or an IaM role as an Authorizer. The short version is that your API endpoints can either be open and public or have an Authorizer, if they have an authorizer then they have to be setup correctly. It is set through the API Gateway config for an endpoint in the Method Request section.
AWS Lambda authorizer info:
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html
AWS Cognito Info:
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html
I am fairly new to lambda and trying to wrap my head around it. I created a basic hello world function and invoked it through
aws lambda invoke
My question is
Dont I have to create an API gateway and expose the lambda function through the API gateway for it work.
How does aws lambda invoke if I have not created a gateway and exposed the function?
You do not have to necessarily create API gateway for invoking lambda function. Every lambda function is already available to be accessed via Amazon's Web Service using API:
POST /2015-03-31/functions/FunctionName/invocations?Qualifier=Qualifier HTTP/1.1
See http://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html for more details.
However, the above API expects that the request payload is signed using aws signature version 4 . The CLI call aws lambda invoke automatically takes care of that piece once you have configured valid access and secret keys.
The API Gateway in front of lambda allows you to add:
Custom resource names
Custom authentication schemes (even no authentication if desired)
Custom way of sending payload
and more...
In summary, API Gateway gives you more control over the API resource and can even abstract the user from internals of AWS API.
I am replatforming an existing application to work with AWS API Gateway and AWS Lambda. The current application exposes it functionality as REST API which is implemented as a Spring Boot application and Spring REST Controller annotations.
While I am able to get the request body JSON from the API Gateway into the Lambda function, in certain cases I would need variables from the Request object as well as path variables accessible in the Lambda function. I did take a look at the Lambda Context object but it did not have anything that could help me in this regard.
Example API URLs: I use a path variable similar to the id variable in
the following API call GET http://www.example.com/users/{id}/alerts.
{id} will be the path variable here. An example of how we use a request variable is in the following URL where the alert id is passed as a query string parameter - GET
http://www.example.com/users/{id}/alerts?id=1234
Is there any recommended way to get this done? I do not want to use the RequestHandler interface as I am aiming to tie each API to a separate Lambda function.
If you are using AWS integration type:
Use a mapping template to send $input.params('id') property in the request body to your Lambda function.
If you are using AWS_PROXY integration type:
You can access the path parameters via the "pathParameters" property of the incoming event. For more details, please read the docs.
I suggest you use the Lambda Proxy integration type, it makes all the information you need available with the least hassle.
So, the properties you need to read will be available as follows:
your /users/... path: event.path
your id in query string: event.queryStringParameters.id
you'll need the http method as well: event.httpMethod
your path parameters like the id one: event.pathParameters
Let me know if you need any more information.
I am facing this error sometimes (not always). I create a resource and a method in an API Gateway function. Then I map it to a Lambda function. On testing it there itself, everything works fine.
Now I add a custom authorization function to the method. Now, if I test it there,
If I do not provide the Authorization header, it works (since it is not deployed yet. After deployment, it would require the Auth header)
If I, however, provide the Authorization token, I get the error:
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/2015-03-31/functions/arn%3Aaws%3Alambda%3Aus-eas
More details: The lambda function belonging to this method was deleted. Then I re-created the function with the same name. And noticed that the method was deleted when the API was deployed. So I re-created the mapping and mapped it to the Lambda function. Since, then I am facing this issue. I am sure if I change the name of the Lambda, it might fix the issue. But I think it's a bug with AWS and not at my end. Need to clarify if there is anything I am doing wrong ?
It looks like the currently deployed version of the API is forwarding the Authorization header from the method request to the integration request (Lambda). If you are trying to fix the current state of your API, then I suggest removing the Authorization header from the method request, which will also remove it from the integration request. This should fix the Lambda signature errors.
If you're trying to use the custom authorizer on a method, you don't need to set up the Authorization header in the method request. You just need to set the authorizer identity source as 'method.request.header.Authorization'