I have been trying to use the Control-M API documentation provided by BMC, and I am unable successfully invoke an API call to it.
When tried to first provide the login credentials using /login resource to get the apiKey which I could use for further resource calls, I get a variety of Error Responses. i.e. 405 method not allowed while using POST, and 404 Page not found while using GET. At this point I am not sure if there is some problem with Control-M API version(9.20.105), or am I using the correct endpoint (CTRLM URL)?
is is not possible via postman?
Note: I am not sure if I am allowed to paste my clients URL here.
I would be really helpful if someone could illustrate a live Control-M API call which is publicly available to test.
If you have an installation of Control-M with automation API you can use its swagger as reference.
Given a Control-M installed on a host named myControlM you should be able to browse to:
https://myControlM:8443/automation-api
I want to handle (create, delete, invoke, list down, update) AWS Lambda functions using REST API calls. I don't have intentions to use AWS console or AWS CLI. Some content in the documentation is unclear to me. I want to know the following things.
Base path or Host path for the API calls
Example request for invoking a lambda function
Base path for API calls will be in this format:
https://lambda.us-west-2.amazonaws.com
So the full path will be
https://lambda.us-west-2.amazonaws.com/2015-03-31/functions/FunctionName/invocations?Qualifier=Qualifier
where the definition for FunctionName and Qualifier can be
found here.
You need to sign the HTTP request using Signature Version 4 with
valid AWS IAM credentials before sending it. The signing process can be found here. Example code for the signing process using Python is given here. Then follow instructions in here to make the invocation request.
I'm attempting to port an existing API to AWS API Gateway.
I've got everything working, in that using the 'test' GUI for each of my endpoints successfully hits my configured EC2 instances.
I used the swagger import facility to automatically map all possible endpoints and their associated URL parameters.
What I've noticed is that when the request hits my API (EC2 instance) the URL has been transformed slightly. The URL parameter order has changed.
Regardless of the parameter order that I paste into the test GUI, the order of the parameters when they hit my API has been changed to the order that they are specified within the 'Method Request' GUI screen.
Does anyone know how to prevent this from happening?
There is no way to achieve this using a lambda 'custom authoriser'
I was trying to use a Lambda function as a custom authoriser which then proxies through to our HTTP API. The only data available to the custom authoriser is the 'Token' in the header (can be named anything you want - setup via API Gateway GUI). You can of course populate this with whatever values you want and one suggestion was to put the param order in this header and then perform some logic at this lambda level, however that meant modifying our API callers which wasn't desirable.
You do have access to the 'transformed' URL (e.g. 'https://df64sxl1.execute-api.us-east-2.amazonaws.com/prod/myEndpoint) but this isn't very useful.
If you are able to utilise lambda integration (instead of custom authorisation) you might be able to achieve what you by using payload-template mappings as these provide a way of accessing the raw request.
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.