I've been working with @keetonian via the slack channel on this issue, I'll defer to him for more details and findings.
In a nutshell:
Swagger is used to define API details. It's included in template with
Location: !Sub 's3://${DeployBucket}/${BranchName}/swagger-${Version}.yaml'
There is a global auth config at the API level with a default authorizer (a lambda authorizer). I wish to make specific get requests defined in the sam template have no authorizer, so I added:
Auth:
Authorizer: NONE
This doesn't seem to stick (it's ignored when deployed) and the DefaultAuthorizer gets added to the resource anyway. Keeton has reproduced the issue, but hasn't nailed down a cause yet. I'm reporting here for tracking and for others should they hit a similar issue. Thanks!
We seem to be experiencing this issue. Is there a known work-around?
We seem to be experiencing this issue. Is there a known work-around?
Kinda- you can have a post-deploy script that uses the CLI to make changes to the gateway/lambda functions. This isn't ideal :/
@sgates @unscriptable Thanks for reporting this bug! Are you facing this while using IAM auth? We have a fix going out soon that addresses it for IAM - https://github.com/awslabs/serverless-application-model/pull/1015. To track our release you can check out our release board.
@praneetap no, this was for using a custom authorizer (lambda authorizer). I didn't try with IAM, but thanks for mentioning it!
We're using Cognito.
@sgates @unscriptable this issue should be fixed in the next release. You can track the release in our release board.
You rock, @ShreyaGangishetty! I don't see 1.16.0 on the release board, yet. Any idea when it's scheduled?
@ShreyaGangishetty, that鈥檚 awesome news, thanks!
@sgates I have created the release tracker for v1.16.0. We haven't cut v1.16.0 release branch yet, but the progress of release can be tracked here
@ShreyaGangishetty Great! We're not blocked at the moment, but we do have a kind of hack-y post deploy script, and this will enable us to get rid of that! Thanks!
The fix for this was reverted in 1.20.0, as it caused multiple regressions in our testing of this release:
@keetonian good to know, will stand by. Looking forward to a fix in the future!
@keetonian @ShreyaGangishetty Any updates on this issue? I am currently experiencing this issue where I can't override an endpoint to use a different Authorizer, it always sets the Default Authorizer.
I am facing the same issue when trying to override an API level Default Authorizer with a Function specific Authorizer. The method still ends up with the Default Authorizer. Is this feature going to be available anytime soon as mentioned in the documentation?
We would also like an update on this fix. Every time we push new changes to the OpenAPI spec, the site goes down for 30 seconds while we run scripts to revert the authorization on the open/unauthenticated endpoints. If the fix isn't being actively developed, we need to know so we can find other (non-SAM and/or non-OpenAPI) ways to implement our API. Thanks!
Most helpful comment
@keetonian @ShreyaGangishetty Any updates on this issue? I am currently experiencing this issue where I can't override an endpoint to use a different Authorizer, it always sets the Default Authorizer.