Comments (9)
Alas, that still feels a bit hacky, since we're relying on the implicit naming scheme for the stage resource (which gets created by the Api resource), as opposed to referring to it directly. I.e. if MyApi resource has a StageName: MyStageName
, then the DependsOn for a UsagePlan resource must list "MyApiMyStageNameStage" literal, otherwise it won't work. This naming scheme is not listed anywhere in the spec AFAIK, thus it may be unreliable (and not very readable).
from serverless-application-model.
So what i had to do to fix this was add DependsOn to the AWS::ApiGateway::UsagePlan as DependsOn: MyApiResourcetestStage
not sure if there is a better way to do this.
from serverless-application-model.
DependsOn is the right solution. Your UsagePlan was being created before the Stage resource.
from serverless-application-model.
@sanathkr, we're seeing the same problem for AWS::ApiGateway::BasePathMapping
as well. Either AWS::Serverless::Api
should wait until its implicit Stage resource is fully created (so other resources that depend on Api may use that stage), or we have to rely on that undocumented Stage resource naming scheme with DependsOn (or just use AWS::ApiGateway::RestApi
instead altogether for such cases).
from serverless-application-model.
The serverless approach is nice and clean but not much mature in the api keys/stages/usage plans area. It creates an extra "Stage" (named "Stage") even if we define our own stage, and the field is mandatory.
I couldn't find a permanent solution for the dirty stacks, and usage plans inside the cloudformation script, so I wrote a bash script that deleted the stage named "Stage" and creates api keys, usage plans then assigns keys to plans. Parsing JSON in the bash, clearing the stages, takes away the clean and neat solution of serverless in the Api gateway : (
Here is the script:
#!/usr/bin/env bash
echo "==============================="
echo "Get id of the api (set output param ApiId in CF)"
echo "==============================="
APIID=$(aws cloudformation describe-stacks \
--stack-name my-stack \
--query 'Stacks[0].Outputs[?OutputKey==`ApiId`].OutputValue' \
--output text)
echo "==============================="
echo "Delete the Stage env"
echo "API ID: ${APIID}"
echo "==============================="
aws apigateway delete-stage \
--rest-api-id ${APIID} \
--stage-name 'Stage'
echo "==============================="
echo "Create usage plan for stage name: v1"
echo "API ID: ${APIID}"
echo "==============================="
USAGEPLANJSON=$(aws apigateway create-usage-plan \
--name "my-usage-plan" \
--description "Usage plan for low usage of api" \
--api-stages apiId="${APIID}",stage='v1' \
--throttle burstLimit=2,rateLimit=1)
echo ${USAGEPLANJSON}
echo "==============================="
echo "Created usage plan for v1"
echo "API ID: ${APIID}"
echo "Getting Usage plan Id for:"
echo "==============================="
USAGEPLANID=$(echo ${USAGEPLANJSON} | python -c 'import sys, json
print(json.load(sys.stdin)["id"])')
echo "==============================="
echo "Creating api key for v1"
echo "==============================="
APIKEYJSON=`aws apigateway create-api-key \
--name 'my-api-key' \
--description 'Used for security of the admin api' \
--enabled`
echo ${APIKEYJSON}
echo "==============================="
echo "Created api key for v1"
echo "==============================="
APIKEYID=$(echo ${APIKEYJSON} | python -c 'import sys, json
print(json.load(sys.stdin)["id"])')
echo "==============================="
echo "Create usage plan key for v1"
echo "API ID: ${APIID}"
echo "USAGE PLAN ID: ${USAGEPLANID}"
echo "API KEY ID: ${APIKEYID}"
echo "==============================="
aws apigateway create-usage-plan-key \
--usage-plan-id ${USAGEPLANID} \
--key-type "API_KEY" \
--key-id ${APIKEYID}
from serverless-application-model.
@bargom DO NOT delete the Stage Stage outside of CloudFormation. You are creating more of a headache for yourself. When you go to deploy a change, CloudFormation will try and update the resource and fail since the resource does not exist. You should never be deleting resources that are controlled by CloudFormation outside of CloudFormation (console, script, etc).
Just leave Stage Stage alone. It isn't harming anything or anyone by being there. Yes, we know this happens. For more info, see #191.
from serverless-application-model.
I see your point. But in my opinion, "Stage"-stage is a security breach. I setup all my keys and environment (usage plans) for the stage I know. So, if I leave the "Stage" there, a developer can guess the endpoint, and can reach it freely. I don't want to leave any open points that I don't have control.
I think also deploying changes over existing API Gateway is a confusing way to deploy. I deploy the full stack with a version number and run it in parallel until everything is confirmed, then switch to new version and delete the old one. I believe if someone following this approach and using API keys, it is best to delete the uncontrolled "Stage".
Thanks for letting me know it causes problems in update. I agree modifying a stack after CF is not ideal, but until there is a solution in serverless framework for usage plans, api keys; I will follow this way.
from serverless-application-model.
@bargom if you are using Lambda proxies you could manage the invocation of the lambda function from your "allowed" stages using the AWS::Lambda::Permission
resource.
This way you could leave the Stage
stage and it cannot be used.
LogicalResourceName:
Type: AWS::Lambda::Permission
Properties:
Action: lambda:InvokeFunction
FunctionName: arn:aws:lambda:region:account-id:function:function-name:alias-name
Principal: apigateway.amazonaws.com
SourceArn: arn:aws:execute-api:region:account-id:api-id/stage-name/*
from serverless-application-model.
@Nr18 that is a great idea. Some of my endpoints are using proxies, but most of them are connecting to lambdas w/o proxy, and some calls are passing parameters (and jwt tokens) to 3rd party API's to create a gateway to external application from internal apps.
from serverless-application-model.
Related Issues (20)
- `AWS::Serverless::Api` creates stage named `Stage` instead of requested stage name HOT 6
- "Invalid OpenAPI input" when OpenAPI set to `3.1.0` HOT 4
- AWS SAM Connector Write needs PutObjectTagging HOT 2
- Setting the runtime of a function to nodejs20.x causes sam validate to fail. HOT 2
- AWS::Serverless::Api - setting "OpenApiVersion" causes "Stage" deployment to be skipped - why? HOT 6
- [Test] GitHub Action automatic comments on GitHub closed Issue HOT 1
- AlwaysDeploy does not include GatewayResponse updates HOT 7
- Please explain how to version AWS::Serverless::Function artifacts cleanly HOT 11
- Bug: AWS::Serverless::Function Policies partly not applied HOT 8
- Cors error from SAM template and Auth enabled. HOT 3
- VSCode SAM Schema Validation Error with !Ref in Conditions Section HOT 7
- Bug: Creates unnecessary AWSLambdaVPCAccessExecutionRole role HOT 7
- Api CORS issue with 500 status after setup Cognito authorizer HOT 3
- Building features for AWS SAM HOT 4
- Can't reset BinaryMediaTypes to a default value for API Gateway REST API HOT 2
- AWS::Serverless::Api auto deploys API when a resource is being added HOT 4
- Layer code update not reflected on Lambda Function HOT 14
- Environment variables not updated HOT 5
- Bug: Using a Ref in StageName is Not Working Properly - Template.yaml HOT 4
- !If not working on Serverless:Function handler HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 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.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
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.
from serverless-application-model.