I'm using AWS API Gateway to create an api.
I have the following path for an API: /users/{id}
Is there a way to validate the existence of id in the API request made and maybe its type in API Gateway before it reaches the Lambda integration? I understand API Gateway supports validating request body, query params and headers, but I can't see any option for path parameters, does API Gateway not support that?
I'm going through the documentation and I can't seem to find something clear on that.
API Gateway can check if a path parameter exists or not. It can check if path includes any "id", but it cannot for example check what is it’s regex pattern. Such validation should be made on a client side. Either the API Gateway path follows the defined pattern, in which case it can route you to an appropriate resource, or not. It can however ensure that request parameters are present and non-blank.
The AWS documentation states that API Gateway can perform the basic validation:
API Gateway can perform the basic validation. This enables you, the
API developer, to focus on app-specific deep validation in the
backend. For the basic validation, API Gateway verifies either or both of the following conditions:
The required request parameters in the URI, query string, and headers of an incoming request are included and non-blank.
The applicable request payload adheres to the configured JSON schema request model of the method.
To enable basic validation, you specify validation rules in a request validator, add the validator to the API's map of request validators, and assign the validator to individual API methods.
Note that comparison with JSON schema request model refers to the request payload, and not to request parameters. In the documentation you can find guidance on how to enable request validation in API Gateway:
by importing OpenAPI
definition
using the API Gateway REST
API
using AWS
console
Also, follow this blog post which explains how to set up request parameters validation. Mind however, that the basic validation ensures that the request parameters are present and non-blank. More advanced validation, like checking regex pattern or type, is not possible to my knowledge.
Related
So I am trying trying to execute a PutItem request from my AWS API Gateway. I am trying to do this by using the path /storeid/{username}/{password}. I have done the mapping as json and the test within the API works perfectly and I see my data show up in my DynamoDB table but when I deploy the API and try to invoke this request I receive the following response: {"message":"Missing Authentication Token"}. This request does not have any authorization or API key requirement. Why does the test work but not the url when invoked.
ps-yes I entered the correct url
Please help!
A few things to check
Verify that Authorization is set to None (i.e. not IAM) in your Method request settings.
Verify that you deployed your API changes to your stage. Using the console, click Actions -> Deploy API.
Once deployed the URL to use should be displayed when you select the Stage that you deployed to. Verify you are using the correct URL.
Also, side note, it is a really bad idea to be putting passwords in your URL path or query parameters. Consider doing sending the data in the request body as a POST and doing something like HTTPS and hashing to protect the password.
I've successfully setup AWS Gateway to validate the body of incoming POST requests using JSON Schema. I was so thrilled! Hooray I thought ... as I tested the functionality using the internal AWS tools ... but then I tested a POST request w/invalid data from a website using AJAX and then a CURL request, again using invalid data - and wouldn't you know it, both of them got through to my integration and triggered my AWS Lambda function, something JSON Schema was supposed to block! I've deployed the latest API to my endpoint and even set all of the "Content-Type" headers being called to the same JSON Schema AWS model. I'm at a loss for what's going on ... how do I enforce that all requests must be one content-type or return an error?
Thanks in advance for any help you could provide ...
The answer to my question for those of you who will stumble upon this issue.
By default, JQuery's ".post" method sets a Content-Type to "application/x-www-form-urlencoded." The model I set in AWs Gateway was only for "application/json" POST requests. I assumed that if I set the "request validator" to use JSON Schema models for a specific content-type that only the ones I defined would allowed to pass through ... oh no, no, no! AWS Gateway conveniently let any other Content-Type pass through unchecked, bypassing my JSON Schema model validator. Unbelievable actually. So the answer to enforce only application/json was to then move to the "integration request" and configure a body mapping for application/json setting the "When there are no templates defined (recommended)" option to true. And voila, problem solved. AWS Gateway will still allow your POST request to get to this stage, but it won't get to your "action (e.g. Lambda function).
I wanted to add ... it's no longer a problem, but even by setting multiple Content-Type patterns, the model was only enforced on the first one within AWS Gateway. Strange behavior ... maybe someone could help w/this?
This works fine using proper setting. Have your model set correctly including the validation you wish to apply.
For your method, go to Method Execution section and set
Settings -> Request Validator - select option as 'Validate Body'. Your may choose other appropriate options based on your requirement.
Request Body -> create new entry as 'application/json' and select your model.
Done. This will work as expected and throw 500 error for other Content-Type or if model validation fails.
Also, you can always validate request in Lambda's entry function. Though that is what you want to avoid to escape lambda trigger cost.
Additional Tip: Make sure you have API Rate limit set properly as you will get charged if your API is caught by spammers/attackers, though validation through model will protect you but you will still get charged by AWS. In case of API Key set, this is still applicable.
Is there a way to validate request in API Gateway based on its body? I need to calculate SHA1 hash of the body to validate the sender - Facebook messenger events... Is there a workaround for it?
ApiGateway does not support passing complete body to custom authorizer.
One option is to have two level of authentication - first just based on header/query parameter ( which api gateway support ) and enough to detect spoof senders. Second can be SHA1 hash based on complete body which you can implement in your backend
I have created an API Key and added it to my functions. I have then deployed the api and tested it but still get:
"message": "Forbidden"
How do I pass the api key with my JSON request as I have been using "x-api-key": "theKey"?
The x-api-key parameter is passed as a HTTP header parameter (i.e. it is not added to the JSON body). How you pass HTTP headers depend on the HTTP client you use.
For example, if you use curl and assuming that you POST the JSON payload, a request would look something like (where you replace [api-id] with the actual id and [region] with the AWS region of your API):
$ curl -X POST -H "x-api-key: theKey" -H "Content-Type: application/json" -d '{"key":"val"}' https://[api-id].execute-api.[region].amazonaws.com
I had to add an API Usage plan, and then link the plan to the API stage.
Seems like this is the only way to link the key to the API, not sure if this is a recent change on AWS.
If you set 'API Key Required' option to true, please check below.
you have to pass 'x-api-key' HTTP Header Parameter to API Gateway.
The API Key had to be created.
In addition, you need to check a Usage Plan for the API Key on API Gateway Console.
If you set 'API' key required to true, you need to pass the api key as header.
API Key is passed as header field 'x-api-key'. Even after adding this field in header, this issue may occur. In that case, please validate below points
Do you have a Usage Plan? if not need to create one.
Link you API with Usage Plan. For that add a stage, it will link your API
Do you have API Key? if not you need to create an API Key and enable it.
Add the Usage Plan which is linked with your API to this API Key. For that, add Usage Plan.
I hope you are not missing to link the API key with the API
I was able to get a successful response from Lambda using below configuration in Postman native app -
Under authorization tab (For some reason this didn't work when i passed the same parameters under header)
Key : x-api-key
Value : your-api-key-value
Add to : Header
I don't have enough reputation to set this as a comment, But I was finally able to find the document specifying that 'x-api-key' belongs in the header for API Gateway calls that come from outside clients (like postman, swagger, etc.) in the AWS Documentation.
The relevant part:
To use header-sourced API keys:
Create an API with desired API methods. And deploy the API to a
stage.
Create a new usage plan or choose an existing one. Add the deployed
API stage to the usage plan. Attach an API key to the usage plan or
choose an existing API key in the plan. Note the chosen API key
value.
Set up API methods to require an API key.
Redeploy the API to the same stage. If you deploy the API to a new
stage, make sure to update the usage plan to attach the new API
stage.
The client can now call the API methods while supplying the x-api-key
header with the chosen API key as the header value.
Choose an API key source
For Private API Gateways accessed through public DNS, we need to pass additional header of 'x-apigw-api-id' with the api id along with 'x-api-key' if configured.
curl -v https://{vpce-id}.execute-api.{region}.vpce.amazonaws.com/test -H 'x-apigw-api-id:{api-id}'
Its documented below,
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-api-test-invoke-url.html#w20aac13c16c28c11
Here a good resource explaining different reasons why we could be getting a Forbidden. The two most important are the request URL and the x-api-key header:
https://{api_id}.execute-api.{region}.amazonaws.com/{stage_name}/{resource_name}
Missing stage name will give you 403 for ex. Maybe for security reasons the response is not revealing an issue with the stage name, and thus you get a generic Forbidden.
I faced the same problem today. I had already mapped the API key to the usage plan (which was linked to the api gateway stage). I was also passing the api key in header correctly.
When none of these solutions work, do remember to check if your API is linked to WAF policy with only a certain ip-addresses permitted. Apparently, my IP address had changed today. So, WAF was blocking me. That can be an additional reason to get {"message": "Forbidden"} error.
Pretty self explanatory title. I'm using API Gateway in AWS, requiring an API key to access a backend written in Django (not using lambda). I need to know how to access the API key used in the request to keep track of who did what at the app level.
You can use mapping templates and get the API Key from the $context variable, it’s the apiKey property inside the identity object: http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#context-variable-reference
Create a mapping template for your requests and include the property in it. For example, if you wanted to include the entire request body + the API Key you would do this:
{
"body": $input.json('$'),
"apiKey": "$context.identity.apiKey"
}
Depending on how your backend application is built, you could send the API key to your application in a HTTP parameter (path, query string, or header) or in the request body. Please have a read through the docs on how to move data between the two systems.
Thanks,
Ryan
Here is how I finally made it work. At the top or bottom of the template, include this line.
#set($context.requestOverride.header.x-api-key = $context.identity.apiKey)
When your backend receives this request, the api key will be in the header x-api-key.
Here is a basic mapping template that just forwards the (json) body and the header.
$input.json("$")
#set($context.requestOverride.header.x-api-key = $context.identity.apiKey)
API Gateway uses the X-API-Key header, so I like for my backend to also use that. That way I can use the same testing commands with only the URL being different.