Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to test API Gateway methods with custom authorizer and empty $context.authorizer.* variables?

I have an API Gateway with a POST method that puts directly to a DynamoDB table. My method is also configured to use a custom authorizer via Lambda.

In my template mapping I'm consuming some of the authorizer variables, such as $context.authorizer.principalId or $context.authorizer.accountId. Simplified template mapping looks as follows:

{ 
"TableName": "$stageVariables.tableName",
"Item": {
    "AccountId": {
        "S": "$context.authorizer.accountId"
        },
    "Id": {
        "S": "$context.requestId"
        },
    "Content": {
        "S": "$input.path('$.content')"
        },
    "UserId": {
        "S": "$context.authorizer.principalId"
        }
}

}

Now, when I make an HTTP request to this API method deployed to a an actual stage, that request will go through the custom authorizer and provide / fill in all $context.authorizer.* variables in the template which might look like this:

{ 
"TableName": "MyTable",
"Item": {
    "AccountId": {
        "S": "12345"
        },
    "Id": {
        "S": "6fd5ff08-34c0-11e7-bf96-591a565835b3"
        },
    "Content": {
        "S": "my content"
        },
    "UserId": {
        "S": "userid-123456789"
        }
}

}

When testing the API method via the API Gateway Test button, the test request is bypassing the custom authorizer (which makes sense, since authorizer can be tested separately) and produces a result like this:

{ 
"TableName": "MyTable",
"Item": {
    "AccountId": {
        "S": ""
        },
    "Id": {
        "S": "test-invoke-request"
        },
    "Content": {
        "S": "my content"
        },
    "UserId": {
        "S": ""
        }
}

}

The following content is now invalid, since all fields get validated against the model, and getting the following validation error:

Endpoint response body before transformations: {"__type":"com.amazon.coral.validate#ValidationException","message":"One or more parameter values were invalid: An AttributeValue may not contain an empty string"}

Is there some way to specify authorizer variables when testing API Gateway methods? Or is there some smart way to define a fallback variable in the template mapping so that when it resolves to empty, it will fall back to, e.g., test-invoke-principalid, just like $context.requestId gets that out of the box?

All I want is to be still able to use the API Gateway test feature while keeping all the validation / authorizer settings in place.

like image 657
jaccus Avatar asked May 10 '17 11:05

jaccus


People also ask

How do I test my API gateway authorizer?

For the REQUEST authorizer, type the valid request parameters corresponding to the specified identity sources and then choose Test. In addition to using the API Gateway console, you can use AWS CLI or an AWS SDK for API Gateway to test invoking an authorizer. To do so using the AWS CLI, see test-invoke-authorizer.

How do I use authorizer API gateway?

EXAMPLE: Create a request-based Lambda authorizer function To create a request-based Lambda authorizer function, enter the following Node. js code in the Lambda console and test it in the API Gateway console as follows. In the Lambda console, choose Create function. Choose Author from scratch.

Which types of custom authorizers are supported by API gateway in AWS?

The API gateway acts as a reverse proxy that accepts all API (Application Programming Interface) calls, aggregates the various services needed to execute them, and returns appropriate results. There are two types of custom authorizers. Tokens and Requests.

How do I pass custom headers via API gateway to a Lambda function using custom Lambda integration?

To pass custom headers from an API Gateway API to a Lambda function, use a body mapping template. The API sends the updated API request to a Lambda function to process the headers. Then, the Lambda function returns one or more header values from the original API request.


1 Answers

Sure we can look at adding placeholders for the test invoke feature. Certainly for the principalId. As for the custom context variables, that might be more difficult, we'll see. We eventually would like to have a better end-to-end testing solution as well.

like image 122
jackko Avatar answered Nov 15 '22 05:11

jackko