The open source version of the Amazon API Gateway Developer Guide. To submit feedback or requests for changes, submit an issue or make changes and submit a pull request.
License: Other
The operationName field is missing from the requestContext of the specification for the AWS Lambda proxy integration request.
Hi, thanks for the developer guide, it's helped me out a lot! 😄
The metric descriptions on the Monitoring WebSocket API execution with CloudWatch metrics page seem a bit inaccurate or insufficient. It'd be great to clarify the ClientError, IntegrationError and ExecutionError metric descriptions.
ClientError is supposedly triggered before the integration is invoked:
But I can trigger it after the integration is invoked. For example, if I connect my WebSocket API to a lambda proxy integration, and make that handler return { statusCode: 400 }, then the ClientError metric increases:
The current description seems misleading, suggesting that ClientError only happens before the integration is invoked - i.e. due to authoriser errors or request validation.
Also, it'd be great if a doc explained how the WebSocket API, API Gateway service, stage, integration, and lambda actually interact. For example, it's not clear why:
statusCodeExecutionError metric increases but not IntegrationError:
In summary, I'd really appreciate your clarification on what the ClientError, IntegrationError and ExecutionError metrics really represent for WebSocket and REST APIs. Thanks 🙂
Hi,
I noticed a dead link in the online documentation.
How to reproduce:
Click on the GitHub icon in the header (next to the PDF one)
The user agent is redirected to:
https://github.com/awsdocs/amazon-api-gateway-developer-guide/tree/master/doc_source/apigateway-override-request-response-parameters.md
The result is a 404:
Cheers!
Hi,
I was looking at the Working with AWS Lambda proxy integrations for HTTP APIs page on the api gateway developer guide and I noticed that the v2 requestContext -> authentication -> issuerDN attribute is missing a closing quote making the event text invalid json. The quote just needs closing after "Example issuer":
"authentication": {
"clientCert": {
"clientCertPem": "CERT_CONTENT",
"subjectDN": "www.example.com",
"issuerDN": "Example issuer",
}Tried to raise a PR on the project to fix as it is a small issue, but the "Edit this page on Github" link points to a file that does not contain the recent clientCert changes. Seems like the site and repo are not in sync.
So far I have tried this:
integration.request.querystring.Message.foo: method.request.path.foo
integration.request.querystring.Message.bar: method.request.path.bar
integration.request.querystring.Message.userId: context.authorizer.claims.sub
But when I make the request via Postman I have this error:
"Error": {
"Code": "MalformedInput",
"Message": "Start of list found where not expected",
"Type": "Sender"
},
Is this even possible? The docs do not mention it
A typical use case could be passing the sub property from the authorizer in the SNS message payload, together with other parameters
Hi!
I think the documentation may be missing "iat" claim instead of the "nbt" claim? Or maybe the HTTP API optionally checks the "nbt" claim only if it's present and ignores the "iat" claim?
AWS Cognito issues Access (OAuth 2.0) and Id (OIDC) Tokens that do not include an "nbt" field (Not-Before) claim, rather, it includes an "iat" (Issued-At) claim. See https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html#amazon-cognito-user-pools-using-the-access-token for reference.
Here's the example payload from "Access Token Payload":
{
"sub": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
"device_key": "us-west-2_"aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
"cognito:groups": [
"admin"
],
"token_use": "access",
"scope": "aws.cognito.signin.user.admin",
"auth_time": 1562190524,
"iss": "https://cognito-idp.us-west-2.amazonaws.com/us-west-2_example",
"exp": 1562194124,
"iat": 1562190524,
"jti": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
"client_id": "57cbishk4j24pabc1234567890",
"username": "[email protected]"
} I was trying to confirm (via the documentation) that I am able to use Use Cognito JWT Access Tokens with HTTP JWT Authorizors.
The Amazon Cognito JWT Access Token does NOT include an "nbt" (Not-Before) claim https://tools.ietf.org/html/rfc7519#section-4.1.5
The Amazon Cognito JWT Access Token does include an "iat" (Issued-At) claim, however: https://tools.ietf.org/html/rfc7519#section-4.1.6
Do API Gateway HTTP API's support validating with the "iat" (Issued-At) claim if the "nbt" (Not-Before) claim is not present, as per Amazon Cognito Access Token Payload?
I've also verified myself with my own application that Amazon Cognito does not include an "nbt" claim, but rather an "iat" claim in the Access and ID JWT Tokens.
In the guide for setting up a Cross-Account Lambda integration with API Gateway:
Step 9 in the last section appears to reference a command that needs to be run, but the command is missing.
In Create a Private API in Amazon API Gateway:
If you choose to enable private DNS, you'll be able to to access your API via private or public DNS
Could not find the corresponding page on GitHub to submit a PR.
I am not sure if this is the best place for this question, but I would say that this could be a problem in the documentation (otherwise in the AWS itself).
In AWS Gateway WebSocket API, I am trying to control the access to my WebSocket endpoint by giving some access rights to some users but not all of them, particularly using IAM, as described in the official docs:
As a test, when I try to Allow/Deny some users with a specific identity using a specific policy (exactly the policy shown in the link above) from connecting to my AWS WebSocket endpoint, this works properly (so controlling the access to $connect works).
My use case is to allow these users to connect (invoke $connect) but to prevent them from invoking some other custom routes (so they will connect and receive some messages but will not be able to invoke specific routes). However, when I try to control the access to any other route (both predefined like $default or any custom route) the connected users are still able to invoke the custom routes even though they are Denyed in the policy.
Could the documentation be missing something? Why are the connected users still able to invoke the other custom secret routes? The policy used is exactly the one provided by the official docs in the link above.
And as said, I know that the policy and the identity are working, because I am able to Deny and Allow the $connect route, but no other routes.
So after a user connects to the WebSocket (that user has the identity that Allows $connect), the user is also able to send the following message (and the message arrives to the handler of the secret route), even though the secret route is denied in the policy.
Notice, invokeCommand is my secret route.
{ "action": "invokeCommand", "command": "Secret route was invoked, but it actually should NOT!" }
I totally do not understand why this route is still invokable.
Here is the Policy I am using:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:eu-central-1:277312736995:gvcpcdepy1/*/$connect"
},
{
"Sid": "VisualEditor1",
"Effect": "Deny",
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:eu-central-1:277312736995:gvcpcdepy1/*/invokeCommand"
}
]
}
Here is the log of the access to the WebSocket API:
2021-05-14T09:41:44.226+02:00 (fVXSzFw4liAFdRA=) Extended Request Id: fVXSzFw4liAFdRA=
2021-05-14T09:41:44.226+02:00 (fVXSzFw4liAFdRA=) Verifying Usage Plan for request: fVXSzFw4liAFdRA=. API Key: API Stage: gvcpcdepy1/dev
2021-05-14T09:41:44.227+02:00 (fVXSzFw4liAFdRA=) API Key authorized because route 'invokeCommand' does not require API Key. Request will not contribute to throttle or quota limits
2021-05-14T09:41:44.227+02:00 (fVXSzFw4liAFdRA=) Usage Plan check succeeded for API Key and API Stage gvcpcdepy1/dev
2021-05-14T09:41:44.228+02:00 (fVXSzFw4liAFdRA=) Starting execution for request: fVXSzFw4liAFdRA=
2021-05-14T09:41:44.228+02:00 (fVXSzFw4liAFdRA=) WebSocket Request Route: [invokeCommand]
2021-05-14T09:41:44.228+02:00 (fVXSzFw4liAFdRA=) WebSocket API [gvcpcdepy1] received message from client [Connection Id: fVXRcdAYliACE8A=].
2021-05-14T09:41:44.228+02:00 (fVXSzFw4liAFdRA=) WebSocket API [gvcpcdepy1] received message from client [fVXRcdAYliACE8A=]. Message: [{"requestContext":{"routeKey":"invokeCommand","messageId":"fVXSzdAuliACE8A=","eventType":"MESSAGE","extendedRequestId":"fVXSzFw4liAFdRA=","requestTime":"14/May/2021:19:41:44 +0000","messageDirection":"IN","stage":"dev","connectedAt":1621021295576,"requestTimeEpoch":1621021304225,"identity":{"sourceIp":"85.127.7.191"},"requestId":"fVXSzFw4liAFdRA=","domainName":"gvcpcdepy1.execute-api.eu-central-1.amazonaws.com","connectionId":"fVXRcdAYliACE8A=","apiId":"gvcpcdepy1"},"body":"{ \"action\": \"invokeCommand\", \"command\": \"DEVICE FIRMWARE VERSION\" }","isBase64Encoded":false}].
2021-05-14T09:41:44.228+02:00 (fVXSzFw4liAFdRA=) Endpoint request URI: https://lambda.eu-central-1.amazonaws.com/2015-03-31/functions/arn:aws:lambda:eu-central-1:277312736995:function:on-controller-dev-invokeCommandHandler/invocations
2021-05-14T09:41:44.228+02:00 (fVXSzFw4liAFdRA=) Endpoint request headers: {x-amzn-lambda-integration-tag=fVXSzFw4liAFdRA=, Authorization=***************************************************************************************************************************************************************************************************************************************************************************************************************************0b7dbc, X-Amz-Date=20210514T194144Z, x-amzn-apigateway-api-id=gvcpcdepy1, X-Amz-Source-Arn=arn:aws:execute-api:eu-central-1:277312736995:gvcpcdepy1/dev/invokeCommand, Accept=application/json, User-Agent=AmazonAPIGateway_gvcpcdepy1, X-Amz-Security-Token=IQoJb3JpZ2luX2VjEGoaDGV1LWNlbnRyYWwtMSJHMEUCIEKlbtIAmHhPU4NtfPnMaH1qTmd5aPQJWGzg52NzdWwFAiEA2bgH6hS8nxIvme60u7PxI4EL6b9+k0oLM2nbQJCrjGAqwwMI8///////////ARACGgw0NzQyNDAxNDY4MDIiDHgoKWJs1yfdnEKQMiqXA5Y2zOztnyyuj2yLzZlYWoAidplaB2/NSj8yFPNKJFo4yZOPc6sLY3MSwJTOhvh2fKtoJ38JUIHYC7hXLmy2ZXwAXD9VBcpadBtdoy8npQdkeS8HZOHYpx/7XmIi+Lkekmj4mkXA3qBLA4RW2vnZwxY0btpSjDGaGLI57sh+zV2 [TRUNCATED]
2021-05-14T09:41:44.228+02:00 (fVXSzFw4liAFdRA=) Endpoint request body after transformations: {"requestContext":{"routeKey":"invokeCommand","messageId":"fVXSzdAuliACE8A=","eventType":"MESSAGE","extendedRequestId":"fVXSzFw4liAFdRA=","requestTime":"14/May/2021:19:41:44 +0000","messageDirection":"IN","stage":"dev","connectedAt":1621021295576,"requestTimeEpoch":1621021304225,"identity":{"sourceIp":"85.127.7.191"},"requestId":"fVXSzFw4liAFdRA=","domainName":"gvcpcdepy1.execute-api.eu-central-1.amazonaws.com","connectionId":"fVXRcdAYliACE8A=","apiId":"gvcpcdepy1"},"body":"{ \"action\": \"invokeCommand\", \"command\": \"DEVICE FIRMWARE VERSION\" }","isBase64Encoded":false}
2021-05-14T09:41:44.228+02:00 (fVXSzFw4liAFdRA=) Sending request to https://lambda.eu-central-1.amazonaws.com/2015-03-31/functions/arn:aws:lambda:eu-central-1:277312736995:function:on-controller-dev-invokeCommandHandler/invocations
2021-05-14T09:41:44.392+02:00 (fVXSzFw4liAFdRA=) Received response. Status: 200, Integration latency: 164 ms
2021-05-14T09:41:44.392+02:00 (fVXSzFw4liAFdRA=) Endpoint response headers: {Date=Fri, 14 May 2021 19:41:44 GMT, Content-Type=application/json, Content-Length=44, Connection=keep-alive, x-amzn-RequestId=9edb5ae5-c7e6-4a62-8d82-a91d7e094759, x-amzn-Remapped-Content-Length=0, X-Amz-Executed-Version=$LATEST, X-Amzn-Trace-Id=root=1-609ed278-d052a897768ba5f05cb18db1;sampled=0}
2021-05-14T09:41:44.392+02:00 (fVXSzFw4liAFdRA=) Endpoint response body before transformations: {"statusCode":200,"body":"Command invoked."}
2021-05-14T09:41:44.392+02:00 (fVXSzFw4liAFdRA=) AWS Integration Endpoint RequestId : 9edb5ae5-c7e6-4a62-8d82-a91d7e094759
2021-05-14T09:41:44.393+02:00 (fVXSzFw4liAFdRA=) Message from client [Connection Id: fVXRcdAYliACE8A=] sent to API [gvcpcdepy1] with response status code [200].
Could any one help me to understand why is this not working or what I can do to get it working?
The page on "@connections Commands" states:
Your backend service can use the following WebSocket connection HTTP requests to send a callback message to a connected client, get connection information, or disconnect the client.
It goes on to describe the callback message procedure, but no further info is given on how to get connection information or how to disconnect the client from the backend.
I found this issue (aws-samples/simple-websockets-chat-app#10) that states an HTTP DELETE request should be sent to the endpoint for terminating connections.
It would be useful to have more information about the available commands and how to execute them.
"Use @connections commands in your backend service" contains a javascript example that is missing indentation.
Customizing HTTP API access logs there is no mention of cloudwatch log retention. Any idea if this is a technical feature missing or something that needs to be adjusted in the doc?
How do you use CDK to make HTTP APIs with Lambda functions?
Just want to do Serverless with CDK because CDK is way simpler than Cloudformation and HTTP api is way simpler than REST api but no infrastructure as code tools support this use case
Here is a great spot for an example:
Documentation for API Gateway V2 request mentions that in the case of native JWT authorizer, claims are inside jwt object under event.requestContext.authorizer
However, what I see in practice is that authorizer information comes in as flat without jwt object.
Here is my authorizer:
resource "aws_apigatewayv2_authorizer" "auth0authorizer" {
name = "auth0authorizer"
api_id = aws_apigatewayv2_api.api.id
authorizer_type = "JWT"
identity_sources = ["$request.header.Authorization"]
jwt_configuration {
audience = [var.api_audience]
issuer = "https://${var.auth0_domain}/"
}
}
And here is the request object
{
"requestContext": {
"accountId": "377258293252",
"apiId": "9kc4yptsm5",
"authorizer": {
"claims": {
"aud": "some.api",
"azp": "FT6TMjfHI2lkxjpAbG5tCjEdiEkyvMCA",
"exp": "1612061676",
"gty": "password",
"iat": "1612053076",
"iss": "https://tenant.auth0.com/",
"scope": "get:data read:policies create:policy",
"sub": "auth0|5fe435b5cbbc85006b071eba"
},
"scopes": null
}
}
The problem with the generated client is it seems tightly coupled to the rest-api-id and stage-name specified so the generated code can’t be used if you want to communicate with a different stage-name or rest-api-id. It may be that i am not using it correctly but it is not clear how I can use the single generated gem for multiple environments. We would like to
generate a single gem and use this gem for each environment, e.g. stage names: devalopera, dev, int, prod.
I have had to do the following:
From the generated code I needed to override some behaviour in https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/APIGateway/Client.html
The method we needed to override is the set_api which sets the https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Seahorse/Model/Api.html.
The instance of this API object is defined in a module within the generated code called ClientApi. I have created a new class which includes this module so we can provide our own initialization of the Seahorse::Model::Api. This is a copy of what is defined in the generated module ClientApi but I swap out some key options like the stage-name and rest-api-id using environment variables.
Hopefully there is a simpler solution to using the generated gem for multiple stage names?
https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-generate-sdk-cli.html
Hi,
Whenever we develop API Gateway stuff, we have headaches with CORS, i know this is just developer guide but can you please ask the API gateway team
would it be possible to allow customers to pass wildcard http status code when we enable cors in method response (especially with Terraform and Cloudformation)?
and really, high-friction CORS process is the #1 most annoying time wasting thing which makes me hate API gateway... i would happily ditch AWS for an API Gateway provider who respected developer time and made it easy to one-click one-liner enable cors for all routes/resources/http codes. I get "security" but when you're developing a tiny react app on local host and you just need a back end fast, and you waste hours to days debugging API gateway CORS BS, it makes you dislike all of AWS, and it makes you want to switch to a different cloud provider
here's how I have to do this now in Terraform:
resource "aws_api_gateway_method_response" "cors_method_response_200" {
rest_api_id = "${aws_api_gateway_rest_api.rest_api.id}"
resource_id = "${aws_api_gateway_resource.proxy.id}"
http_method = "${aws_api_gateway_method.any.http_method}"
status_code = "200"
response_parameters = {
"method.response.header.Access-Control-Allow-Origin" = true
}
depends_on = ["aws_api_gateway_method.any"]
}
if you put status_code = "" then you get:
Error: ValidationException: 1 validation error detected: Value '' at 'statusCode' failed to satisfy constraint: Member must satisfy regular expression pattern: [1-5]\d\d
but there's SO MANY STATUS CODES:
200 OK
300 Multiple Choices
301 Moved Permanently
302 Found
304 Not Modified
307 Temporary Redirect
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
410 Gone
500 Internal Server Error
501 Not Implemented
503 Service Unavailable
550 Permission denied
How do you expect API Gateway customers to write out this much boilerplate ~15 times just so we can actually see our API error messages on localhost:3000 ??? sigh. I just want to focus on my app, not your boilerplate, not struggle with API gateway gotchas
Please make this easier,
Thanks in advance for any progress on the matter
Bionicles
In doc_source/api-gateway-request-throttling.md:
If the caller submits 5,000 requests in the first millisecond and waits until the 101st millisecond to submit another 5,000 requests, API Gateway processes 6,000 requests and throttles the rest in the one-second period. This is because at the rate of 10,000 rps, API Gateway has served 1,000 requests after the first 100 milliseconds and thus emptied the bucket by the same amount. Of the next spike of 5,000 requests, 1,000 fill the bucket and are queued to be processed. The other 4,000 exceed the bucket capacity and are discarded.
It should be that 5,500 requests are processed since:
the issuer in the tokens from google [and a lot of other providers] is on the format: "accounts.google.com"
but it seems the jwt-authorizer config requires an issuer url with "https://" in front
That means the google tokens never be accepted by the authorizer since the token iss claim is missing: https
Is this assumption correct? I am hoping that the documentation is missing that gives the authorizer slack on this so it can be configured to work.
I am trying to use stage variables, but I always get this error:
{
"logref": "some_uid",
"message": "Invalid stage variable value: null. Please use values with alphanumeric characters and the symbols ' ', -', '.', '_', ':', '/', '?', '&', '=', and ','."
}
My goal is to call SNS from API gateway without the need from the caller to specify the TopicArn and the Message in the query string.
So in the Integration Request I am mapping the query string TopicArn to stageVariables.TopicArn (I have tried '$stageVariables.TopicArn' as well).
And then in the Stage variables section in AWS console I input the Name TopicArn and the Value arn:aws:sns:my_region:my_account_id:test-topic
After I deployed my API I test it from the AWS console and I get this error:
{
"logref": "some_uid",
"message": "Invalid stage variable value: null. Please use values with alphanumeric characters and the symbols ' ', -', '.', '_', ':', '/', '?', '&', '=', and ','."
}
What am I doing wrong, it his achievable?
The document for adding policies to a API gateway only has JSON examples ... It would be helpful to update the second example blocks with the yaml equivalent.
Build an API Gateway API with Lambda Proxy Integration says you will get the following response when you test it with cURL:
"message": "Good day, John of Seattle. Happy Friday!",
but actually you will get
"message": "Good day, you of Seattle. Happy Friday!",
Although the request body has "callerName": "John", it isn't used.
Under Step 4 of the "Create a REST API with Lambda Integration" it suggests using the Node.js 8.10 runtime which is about to go EOL next month.
For example, callerName doesn't appear anywhere in the code, but it is accepted in a POST body at '(https://)r275xc9bmd.execute-api.us-west-2.amazonaws.com/test/Seattle?time=evening'
Also the "time" parameter is only accepted in a request-body, not as shown in a query string. (The documentation correctly reports the results as "good day")
Anyways... is the code running at (https://)r275xc9bmd.execute-api.us-west-2.amazonaws.com publicly available?
Enhancement Request:
Add metadata and descriptions to the documentation export.
According to this post on amplify github, amplify is only meant for use cases with AWS Cognito. The AWS Docs are not clear about this, and seems to indicate that amplify can be used with or without Cognito: https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-call-api-using-aws-amplify-javascript-library.html
The example suggesting the use of x-amazon-apigateway-integrations object under components for storing the x-amazon-apigateway-integration objects does not work.
Upon loading the example code from api-gateway-extensions-integrations.md in the Import API parser textarea (and attempting to import it), the code does not detect the Objects stored under components.x-amazon-apigateway-integrations referenced with $ref within the operation definitions and following errors are displayed:
Your API was not imported due to errors in the Swagger file.
Unknown integration type 'null' for 'GET /'. Ignoring.
Unknown integration type 'null' for 'GET /pets'. Ignoring.
Unknown integration type 'null' for 'GET /checkout'. Ignoring.
x-amazon-apigateway-integration objects stored in components.x-amazon-apigateway-integrations and referenced by $ref should be read in properly.Hi,
I just found another very important difference between HTTP vs. REST API. The support for VPC Link to an ALB is only supported by the HTTP API. This will enable secure communication to private ALB in private subnets.
You published also published a blog article where you show how to configure it.
Please reflect these differences on the documentation on the page - https://github.com/awsdocs/amazon-api-gateway-developer-guide/blob/main/doc_source/http-api-vs-rest.md
References/Links:
Let's say I want to set header mappings for a 'post' method.
I set the value of Response header to be Access-Control-Allow-Origin and mapping value "".
It throws an error: 'Invalid mapping expression specified: Validation Result: warnings : [], errors : [Invalid mapping expression specified: ""]'. Now I change the mapping value to '*' which fixes the error. But the error is still hanging up there in the console which misleads the user into thinking the fix is wrong.
Hello,
the steps present in the guide here are outdated since the API gateway is different now, is it possible to update this to hold the new steps to follow?
Thanks;
We've just figured out there is a way to define the minimum compression size using the ApiGateway Import API with a swagger file using the swagger extension x-amazon-apigateway-minimum-compression-size. It would be nice if this would be documented side-by-side with the other swagger extensions.
According to the start page for an API Gateway in eu-west-1, HTTP API supports lambda
but according to the difference between http api and rest, it doesn't
On this page it's stated that In API Gateway, the API request and response have a text or binary payload. A text payload is a UTF-8-encoded JSON string. A binary payload is anything other than a text payload. However, this leaves ambiguity in trying to set up an integration for multipart/form-data, which is essentially a mixture of the two.
Also, the page is lacking documentation for non-lambda proxy integrations (http_proxy). It only talks about lambda proxy and non-proxy integrations.
it seems like documentation is not comprehensive lots of steps and information are missing.
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html
this article seems to be out of date. Many of these steps are non-existant in the AWS API Gateway console. Specifically steps 16-20
The first paragraph under Transforming API requests section of the HTTP API Parameter mapping doc says the following:
You use request parameters to change requests before they reach your backend integrations. You can modify headers, query strings, the request path, or the request body.
Notice how at the end, it's stated that the request body is transformable. This is then refused by the Parameter mapping keys table which does not include the request body as transformable key.
I also tried this through an actual AWS HTTP API and noticed that the available parameters to modify are the same as the ones mentioned in the table.
This is also backed by the HTTP vs REST doc which mentions that request body transformations are not supported in HTTP APIs.
I'm happy to create the PR myself but I'd like if someone can verify my analysis is correct.
The @connections REST endpoint can be accessed through the API Gateway Management API library. There's no mention of this library anywhere in the Websocket documentation. This library takes care of signing and generating the REST requests necessary to send messages through the websocket.
There's no mention of the library anywhere.
Please add a reference to it. I had to cook my own SigV4 URL signer, which a wasn't particularly pleasant task.
The corresponding GitHub link for the Create a Private API in Amazon API Gateway documentation page is missing/broken.
Hi,
I am wondering what is the use of region-specific API Gateway account IDs?
for example,
ap-southeast-2 | 798376113853
https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-api-with-vpclink-accounts.html
Thanks
There is no documentation on the format of the event.requestContext.authorizer.claims, as provided by the API Gateway Cognito Authorizer. This is a problem, because one would expect the payload of the JWT (token) to be the same in both the encoded token itself, and the contents of event.requestContext.authorizer.claims provided to the lambda integration.
The disparity in these values can be seen in any logs, because all of the values of the token's payload in the event.requestContext.authorizer.claims are strings (as opposed to actual values (numbers, arrays, timestamps etc. in the JWT payload), resulting in the need to parse these manually when working with cognito authorizer.
I have outlined this issue better in this StackOverflow post.
I need sent all clients to same message. Is there any solution for that
Here is the description of "Principal" in Access Policy for API Gateway
Principal – The account or user who is allowed access to the actions and resources in the statement. In a resource policy, the principal is the IAM user or account who is the recipient of this permission
Needs to clarify if the principal can be an IAM Role. If yes, it should read as:
Principal – The account or user who is allowed access to the actions and resources in the statement. In a resource policy, the principal is the IAM user, role or account who is the recipient of this permission
At the end of the sample, the curl invocation adds the following request header.
-H 'x-amnz-RequestId:123344566'
First of all, I'm not sure why an inbound request would even have this (perhaps simulating another AWS service?). But in any case, the amnz portion should probably be amzn. It causes the x-amzn-request in the response to be overridden, which I believe was the intended effect.
I didn't include a pull request for the typo because fixing the type also impacts the response of the curl command. I don't have PetStore installed to definitively determine the correct response. Just for illustration purposes, here is the difference on my sample API.
In this case, the x-amzn-requestid response header was the usual UUID format.
$ curl -H "x-amnz-RequestId:12345678" https://api-dev.sample.org/abc -i
HTTP/2 404
date: Fri, 17 Apr 2020 15:17:12 GMT
content-type: application/json
content-length: 146
x-amzn-requestid: 68c4fad4-ca27-49cb-a46d-9603999d8ea2
x-amzn-errortype: MissingAuthenticationTokenException
x-amz-apigw-id: LIxCyGd7SK4FjEg=
In this case, x-amzn-requestid reflects the input request header.
$ curl -H "x-amzn-RequestId:12345678" https://api-dev.sample.org/abc -i
HTTP/2 404
date: Fri, 17 Apr 2020 15:16:34 GMT
content-type: application/json
content-length: 146
x-amzn-requestid: 12345678
x-amzn-errortype: MissingAuthenticationTokenException
x-request-id: 12345678
x-amz-apigw-id: LIw84EkUSK4FUcA=
It seems to me that the JWT-authorizer in a HTTP-api on AWS API-Gateway does not support adding "any client" as allowed audience.
I think this becomes a problem in the case you want to use it for an API where clients get added removed a lot (or when many clients are to be supported).
Am I missing something (an asterix or something in the configuration), or can't the JWT-authorizer support such cases where clients are added/removed dynamically outside of the IAC?
I am reading the docs here:
Audience : Required for the JWT authorizer type
The section Configure a backend HTTPS server to verify the client certificate links to CLI v1 (https://docs.aws.amazon.com/cli/latest/reference/apigateway/get-client-certificate.html)
I suspect it should link to CLI v2 (https://awscli.amazonaws.com/v2/documentation/api/latest/reference/apigateway/get-client-certificate.html) ?
If you have ideas about any areas of confusion that I should address in our Amazon API Gateway Developer Guide, please let me know!
Submit a pull request as explained in these directions: https://github.com/awsdocs/amazon-s3-developer-guide/blob/master/CONTRIBUTING.md .
I look forward to hearing from you.
In the section "How to Invoke a Private API":
- In the Details pane, you'll see 4 values in the DNS names field. The first 2 are the private DNS names for your API. The other 2 are the public DNS names for it.
Does not look like the Details pane displays those 2 private and 2 public DNS names.
I see one DNS name for the VPC Endpoint (that resolves to a private IP, even outside of the AWS cloud).
Plus additional DNS names for each AZ (resolves to private IPs too).
I'm confused.
See attached screenshot: VPC Endpoint Details
This is a problem with both the documentation and the UI: it's not clear how to set up a mapping template for a particular Integration Request in the Websocket API console.
I tried to create a Mapping Template for the $connection route in order to add the context variables to the Integration Request in an HTTP integration.
In my case, the UI requires you to:
This is not detailed in the documentation, and it should definitely be. It's confusing from beginning to end.
Following the steps in Map Request Parameters for an API Gateway API as part of api-gateway-create-api-step-by-step.md, when I get to creating the GET method for http://petstore-demo-endpoint.execute-api.com/petstore/pets/{id} and mapping method.request.path.petId to id I get the error:
Invalid mapping expression specified: Validation Result: warnings : [], errors : [Invalid mapping expression parameter specified: method.request.path.petId]
I've tried swapping the parameter names around but still get the same error.
I also get the following warnings next to the endpoint URL:
The endpoint you have entered does not contain all of the path parameters for the resource. You can include path parameters by surrounding them in curly braces (eg. {resourceId})
The endpoint you have entered contains parameters that are not defined in the resource path. Parameters are case sensitive.
Hi ,
Your document has a screen for setting "ClientCert" for Testing, I dont see any option in Testing section can you clarify ?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.