Setting HTTP Proxy on AWS API Gateway via Cloudformation - azure

Thanks for the help in advance.
Currently using cloudformation templates to deploy a simple API to AWS as part of a POC for moving from Azure to AWS API management.
I have got everything working except i have not been able to figure out the YAML AWS extension for setting the HTTP proxy checkbox for the HTTP request.
Sample YAML below. I know this will not set that checkbox (as i have tested it and it worked minus that problem), but on this page
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions-integration.html
i cannot see a extension that sets this option? Has AWS not done this yet
AWSTemplateFormatVersion: '2010-09-09'
Resources:
PlayersAPI:
Type: AWS::ApiGateway::RestApi
Properties:
Name: RAH API
Description: A demo API for testing
Body:
swagger: '2.0'
info:
title: test api
description: test api
version: 1.0.1
contact:
name: SH
email: test#mailinator.com
paths:
"/heartbeat":
get:
description: Checks the API is working
produces:
- application/json
responses:
'200':
description: API Response information
x-amazon-apigateway-integration:
type: http
responses:
default:
statusCode: '200'
httpMethod: GET
uri: https://api.example.com

This works for me:
resources:
Resources:
ProxyResource:
Type: AWS::ApiGateway::Resource
Properties:
ParentId:
Fn::GetAtt:
- ApiGatewayRestApi # our default Rest API logical ID
- RootResourceId
PathPart: "{proxy+}" # the endpoint in your API that is set as proxy
RestApiId:
Ref: ApiGatewayRestApi
ProxyMethod:
Type: AWS::ApiGateway::Method
Properties:
ResourceId:
Ref: ProxyResource
RestApiId:
Ref: ApiGatewayRestApi
HttpMethod: GET # the method of your proxy. Is it GET or POST or ... ?
MethodResponses:
- StatusCode: 200
Integration:
IntegrationHttpMethod: GET
Type: HTTP_PROXY
Uri: http://bucket.mybucket.co.s3.eu-west-1.amazonaws.com/{proxy} # the URL you want to set a proxy to
IntegrationResponses:
- StatusCode: 200
AuthorizationType: NONE

Related

Lambda#edge not triggered by an origin-request event

I'm trying to configure Lambda#edge functions using CloudFormation. After deploying the template everything looks find in the console, however the lambda functions listening to origin-request events are not being triggered.
Strange enough, a viewer-request event does manage to trigger a function.
What am I doing wrong? How can I make the origin-request event to work?
Here's my template:
AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Description: Deployment of Lambda#edge functions
Parameters:
Stage:
Type: String
AllowedValues:
- staging
- production
Default: staging
Description: Stage that can be added to resource names
CodeBucket:
Type: String
Description: The S3 Bucket name for latest code upload
CodeKey:
Type: String
Description: The S3 Key for latest code upload
# Mappings:
# AliasMap:
# staging:
# Alias: "staging-app.achrafsouk.com"
# production:
# Alias: "app.achrafsouk.com"
Resources:
CFDistribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Enabled: true
Logging:
Bucket: XXX.s3.amazonaws.com
IncludeCookies: false
Prefix: !Sub ${Stage}
PriceClass: PriceClass_100
Comment:
!Sub "Lambda#Edge - ${Stage}"
# Aliases:
# - !FindInMap [AliasMap,
# Ref: Stage, Alias]
Origins:
- CustomOriginConfig:
OriginProtocolPolicy: https-only
DomainName: !Sub "${Stage}.defaultOrigin.example.com"
Id: defaultOrigin
OriginCustomHeaders:
- HeaderName: X-Node-Env
HeaderValue: !Sub "${Stage}"
- CustomOriginConfig:
OriginProtocolPolicy: https-only
DomainName: !Sub "${Stage}.another.example.com"
Id: rateLimitsOrigin
OriginCustomHeaders:
- HeaderName: X-Node-Env
HeaderValue: !Sub "${Stage}"
DefaultCacheBehavior:
ForwardedValues:
Headers:
- CloudFront-Viewer-Country
- X-Request-Host
- User-Agent
QueryString: true
ViewerProtocolPolicy: https-only
TargetOriginId: defaultOrigin
DefaultTTL: 0
MaxTTL: 0
LambdaFunctionAssociations:
# - EventType: viewer-request
# LambdaFunctionARN:
# Ref: ViewerRequestLambdaFunction.Version
- EventType: origin-request
LambdaFunctionARN:
Ref: OriginRequestLambdaFunction.Version
CacheBehaviors:
- ForwardedValues:
Headers:
- CloudFront-Viewer-Country
- X-Request-Host
- User-Agent
QueryString: true
ViewerProtocolPolicy: https-only
DefaultTTL: 60
MaxTTL: 60
TargetOriginId: rateLimitsOrigin
PathPattern: "/rate-limit*"
LambdaFunctionAssociations:
- EventType: origin-request
LambdaFunctionARN:
Ref: GetRateLimitLambdaFunction.Version
# ViewerRequestLambdaFunction:
# Type: AWS::Serverless::Function
# Properties:
# CodeUri:
# Bucket: !Sub ${CodeBucket}
# Key: !Sub ${CodeKey}
# Role: !GetAtt LambdaEdgeFunctionRole.Arn
# Runtime: nodejs10.x
# Handler: src/functions/viewerRequest.handler
# Timeout: 5
# AutoPublishAlias: live
OriginRequestLambdaFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri:
Bucket: !Sub ${CodeBucket}
Key: !Sub ${CodeKey}
Role: !GetAtt LambdaEdgeFunctionRole.Arn
Runtime: nodejs10.x
Handler: src/functions/originRequest.handler
Timeout: 5
AutoPublishAlias: live
GetRateLimitLambdaFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri:
Bucket: !Sub ${CodeBucket}
Key: !Sub ${CodeKey}
Role: !GetAtt LambdaEdgeFunctionRole.Arn
Runtime: nodejs10.x
Handler: src/functions/getRateLimit.handler
Timeout: 5
AutoPublishAlias: live
LambdaEdgeFunctionRole:
Type: "AWS::IAM::Role"
Properties:
Path: "/"
ManagedPolicyArns:
- "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: "AllowLambdaServiceToAssumeRole"
Effect: "Allow"
Action:
- "sts:AssumeRole"
Principal:
Service:
- "lambda.amazonaws.com"
- "edgelambda.amazonaws.com"
Outputs:
# ViewerRequestLambdaFunctionVersion:
# Value: !Ref ViewerRequestLambdaFunction.Version
OriginRequestLambdaFunctionVersion:
Value: !Ref OriginRequestLambdaFunction.Version
GetRateLimitLambdaFunctionVersion:
Value: !Ref GetRateLimitLambdaFunction.Version
CFDistribution:
Description: Cloudfront Distribution Domain Name
Value: !GetAtt CFDistribution.DomainName
So, after painful hours of trial and error the solution was staring me in the face:
CloudFront distribution was emitting and error saying it could not connect to the origin, and it was right - because I've specified dummy domains in the origins definition of the CloudFront distribution.
My logic was that if my lambda#edge functions intercept the requests before reaching the origin, then it shouldn't matter if the origin's domains is real or not.
As it turns out, it's partially true. Because it seams that:
viewer-request event is triggered before trying to connect to the origin, and there for it can by fake.
origin-request event is triggered only after trying to connect to the origin, so you'd need to specify something real.
Hope my wasited hours will contribute to someone else exploring the same path of reasoning.
In case it helps someone in future with this problem - I noticed that origin-response (which I accidentally selected instead of origin-request) events were (mostly) working for me, but there were still a large number of OriginConnectError in the logs, and the "Percentage of Viewer Requests by Result Type" report was showing a high error rate.
It turns out it was only working at all because I had my origin connection set to https-only, but my origin (an empty s3 bucket) only accepted http connections - and for some reason the events were still being triggered.
Changing the origin connection to the correct http-only completely stopped things working for origin-response, until I also corrected the event type to origin-request
So, in general, check the OriginProtocolPolicy is http-only if you're using an s3 bucket origin. If it's wrong, things might still appear to work sometimes, but not always, and you'll end up with high error rates.

How to use node.js to implement multipart/form-data in openapi3's yaml file?

I'm setting up a new server and my goal is to implement multipart/form-data in OpenApi3.0's yaml file. I encounter "should NOT have additional properties (consume)" error in Node.js and wanna know how to fix this error or how to implement multipart/form-data in OpenApi3.0's yaml file?
This is my OpenApi3.0's yaml file to implement this goal, it will report the error I mentioned above.
openapi: 3.0.1
info:
title: myapp
description: My cool app
version: 1.0.0
servers:
- url: /api/v1/user
tags:
- name: User
description: User Operations
paths:
/onboarding/signature:
post:
tags:
- User
description: Onboarding Upload Signature API - with parameters user's email and image file
requestBody:
description: Request Body {email, image}
content:
multipart/form-data:
schema:
$ref: '#/components/schemas/onboardingSignature'
required: true
responses:
200:
description: OK
201:
description: Created
400:
description: Bad Request
500:
description: Internal Server Error
components:
schemas:
onboardingSignature:
description: Onboarding Signature File
type: object
properties:
email:
type: string
image:
format: binary
I expect the implementation of uploading file in Swagger use multipart/form-data format.

Invalid HTTP endpoint specified for URI in Amazon ApiGateway

I am trying to create a resource /user/devices with GET method for API Gateway using cloudformation template but it is giving me a below error
An error occurred: ApiGatewayRootMethod - Invalid HTTP endpoint specified for URI (Service: AmazonApiGateway; Status Code: 400; Error Code: BadRequestException; Request ID:xxxxxxxxxx)
Below is my cloudformation template,
AWSTemplateFormatVersion: 2018-11-13
Description: test user
resources:
Resources:
UserDeviceApiGateway:
Type: "AWS::ApiGateway::RestApi"
Properties:
Name: "test-user-info"
Description: "Fetch the user"
UserResource:
Type: 'AWS::ApiGateway::Resource'
Properties:
ParentId:
Fn::GetAtt: ["UserDeviceApiGateway","RootResourceId"]
RestApiId:
Ref: "UserDeviceApiGateway"
PathPart: 'user'
Resource:
Type: 'AWS::ApiGateway::Resource'
Properties:
ParentId:
Ref: "UserResource"
RestApiId:
Ref: "UserDeviceApiGateway"
PathPart: 'devices'
ApiGatewayRootMethod:
Type: "AWS::ApiGateway::Method"
Properties:
AuthorizationType: "NONE"
HttpMethod: "GET"
Integration:
IntegrationHttpMethod: "GET"
Type: "HTTP"
Uri: Sub
- "arn:aws:apigateway:arn:aws:lambda:eu-west-1:lambda:path/2015-03-31/functions/arn:aws:lambda:eu-west-1:xxxxxxxx:function:user-device-lambda/invocations"
ResourceId:
Fn::GetAtt: ["UserDeviceApiGateway","RootResourceId"]
RestApiId:
Ref: "UserDeviceApiGateway"
Deployment:
DependsOn:
- ApiGatewayRootMethod
Type: 'AWS::ApiGateway::Deployment'
Properties:
RestApiId:
Ref: "UserDeviceApiGateway"
StageName: dev
A little late to the party but...
You specify Type: "HTTP" for ApiGatewayRootMethod but HTTP takes the API endpoint URL. The URI formation that you specify is taken by Type: "AWS".
From AWS docs:
The Uniform Resource Identifier (URI) for the integration.
If you specify HTTP for the Type property, specify the API endpoint URL.
If you specify MOCK for the Type property, don't specify this property.
If you specify AWS for the Type property, specify an AWS service that follows this form: arn:aws:apigateway:region:subdomain.service|service:path|action/service_api. For example, a Lambda function URI follows this form: arn:aws:apigateway:region:lambda:path/path. The path is usually in the form /2015-03-31/functions/LambdaFunctionARN/invocations. For more information, see the uri property of the Integration resource in the Amazon API Gateway REST API Reference.
If you specified HTTP or AWS for the Type property, you must specify this property.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apitgateway-method-integration.html

API gateway : Bluemix

I have an issue with the embedded API management within a Cloud Foundry application ( node.js ) on bluemix .There is a certain path in the yaml which is not working via the gateway, please see below the relevant path from the yaml:
/socket.io/:
get:
produces:
- text/plain; charset=utf-8
parameters: []
responses:
default:
description: Definition generated from Swagger Inspector
I get 404 , not found.
The url works fine when I dont go via the gateway.
The url is https://[masked api mgd hostname]/socket.io/?EIO=3&transport=polling&t=MC0pE73
Please help.
Find attached the complete yaml below
swagger: "2.0"
info:
description: defaultDescription
version: "0.1"
title: defaultTitle
host: masked.actualEndpoint
schemes:
- https
basePath: "/"
paths:
/socket.io/:
get:
parameters:
- name: t
in: query
required: false
type: string
x-example: MC0pE73
- name: EIO
in: query
required: false
type: string
x-example: "3"
- name: transport
in: query
required: false
type: string
x-example: polling
responses:
default:
description: Definition generated from Swagger Inspector
definitions: {}
am accessing the url using https://[ masked api mangd hostname ]/socket.io/?EIO=3&transport=polling&t=MCvtHJT
I believe its the / at the end of the path ( /socket.io/ ) which is causing the gateway to fail. Any comments.

Swagger validation failed in Yaml file

I have a swagger yaml specification like this :
swagger: "2.0"
info:
version: "0.0.1"
title: Chat API
# during dev, should point to your local machine
host: localhost:5000
# basePath prefixes all resource paths
basePath: /api/v2
#
schemes:
# tip: remove http to make production-grade
- http
- https
# format of bodies a client can send (Content-Type)
consumes:
- application/json
# format of the responses to the client (Accepts)
produces:
- application/json
paths:
/room:
post:
summary: Get room
operationId: getRoom
tags:
- room
parameters:
-
name: token
in: header
description: "token to be passed as a header"
default: "ZjE4YjMxNmY3OGEzNDMyN2JiYjJmYTQwMDBjODg4OWM="
required: true
-
name: room_id
in: body
description: "get room"
required: true
schema:
$ref: "#/definitions/Room"
definitions:
Room:
required:
- room_id
properties:
room_id:
type: string
This yaml file is compiled well without the header part. If I include the header in the paramerts . The nodejs app keep throwing : "Swagger validation errors"
-
name: token
in: header
description: "token to be passed as a header"
default: "ZjE4YjMxNmY3OGEzNDMyN2JiYjJmYTQwMDBjODg4OWM="
required: true
I don't know what was wrong in this part. I want to add the header to this spec file.
You simply need to add the type attribute. Swagger doesn't know if this is a string, an integer, etc. (although one could say the default explains it).
- name: token
in: header
description: "token to be passed as a header"
default: "ZjE4YjMxNmY3OGEzNDMyN2JiYjJmYTQwMDBjODg4OWM="
required: true
type: string

Resources