Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow explicit AWS::NoValue for Api Gateway Default Authorizer #3321

Closed
wants to merge 4 commits into from

Conversation

ethanmills
Copy link

@ethanmills ethanmills commented Aug 24, 2023

Issue #, if available

#3313

Description of changes

Change to schema and implementation to allow an explicit No Value for the API gateway default authoriser.

Description of how you validated changes

To do

Checklist

Examples?

Please reach out in the comments if you want to add an example. Examples will be
added to sam init through aws/aws-sam-cli-app-templates.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Copy link
Contributor

@aaythapa aaythapa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests and schema stuff looks good. Looking at the request you say

It would be great if SAM could accept an explicit None in the DefaultAuthorizer when there are authorizers configured.

I thought this meant you like to do DefaultAuthorizer: None. Does AWS::NoValue solve that usecase and why that over just allowing NONE in DefaultAuthorizer? (I'm not too familiar with AWS::NoValue so might just be going over my head)

api_with_auth_explicit_no_default.yaml Outdated Show resolved Hide resolved
@ethanmills
Copy link
Author

Tests and schema stuff looks good. Looking at the request you say

It would be great if SAM could accept an explicit None in the DefaultAuthorizer when there are authorizers configured.

I thought this meant you like to do DefaultAuthorizer: None. Does AWS::NoValue solve that usecase and why that over just allowing NONE in DefaultAuthorizer? (I'm not too familiar with AWS::NoValue so might just be going over my head)

That was my original plan, but I did this because of the discussion over in #3313 (comment). I think DefaultAuthorizer: None would technically be a breaking change, because there's nothing to stop someone from having defined an authorizer called None previously.

…rizer

Use AWS::NoValue rather than NONE to preserve backwards compatibility with any templates that have authorizers named NONE
@ethanmills ethanmills marked this pull request as ready for review October 10, 2023 11:20
@ethanmills ethanmills requested a review from a team as a code owner October 10, 2023 11:20
@ethanmills
Copy link
Author

@aaythapa Sorry for leaving this for so long, I ran out of time to work on this. I looked at adding integration tests for this (and would be happy to do so if you'd like) but given the nature of the transformation I think the existing tests cover this entirely.

@ethanmills
Copy link
Author

May be worth adding an example to document this, but I've updated the schema to reflect. It looks like this was already implemented in code for the HttpApi, but not in the schema (now fixed)

@ethanmills
Copy link
Author

Am I right in thinking these test failures are unrelated to my change?

@aaythapa
Copy link
Contributor

aaythapa commented Oct 11, 2023

@ethanmills thanks for taking on this PR again. Yep, those failures are unrelated to your changes, I'm going to push a change soon to fix that and then review your code. Thanks again

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test file seems redundant. From what I can tell you use Ref: AWS::NoValue here and use !Ref AWS::NoValue in tests/translator/input/api_with_auth_explicit_inline_no_default.yaml. I think its ok if we only test one (if anything you can have a mix of both in one file). Let me know if there are more differences I didn't spot

CodeUri: s3://bucket/key
Handler: index.handler
Runtime: nodejs12.x
Events:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lot of these Events seem duplicated and add needless complexity to this test. Could we make this simpler somehow while still being thorough? For example I don't think we need to test for different paths since I don't believe that will make a difference in the output.

@aaythapa
Copy link
Contributor

aaythapa commented Oct 16, 2023

@aaythapa Sorry for leaving this for so long, I ran out of time to work on this. I looked at adding integration tests for this (and would be happy to do so if you'd like) but given the nature of the transformation I think the existing tests cover this entirely.

Thanks again for taking this on. Since your change uses intrinsics I would feel more comfortable if you added integration tests. Something simple should do, just to test the behavior is as expected. Other than that and the few comments i added the PR lgtm

@GavinZZ
Copy link
Contributor

GavinZZ commented Oct 25, 2023

Thanks for the contribution. Really appreciate that you spend the time and effort to create it. However, I have one question. Have you tried out using DefaultAuthorizer: null?

I had a quick test and it seems to work for me without making any changes to the code. Here is my sample template:

Resources:
  HttpApiFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: s3://sam-demo-bucket/todo_list.zip
      Handler: index.restapi
      Runtime: python3.7
      Events:
        DefaultAuth:
          Type: HttpApi
          Properties:
            Path: /default
            Method: post
            ApiId: !Ref MyApi
        SpecifiedAuth:
          Type: HttpApi
          Properties:
            Path: /specified
            Method: get
            ApiId: !Ref MyApi
            Auth:
              Authorizer: LambdaAuth
  MyAuthFn:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: s3://bucket/key
      Handler: index.handler
      Runtime: nodejs12.x

  MyApi:
    Type: AWS::Serverless::HttpApi
    Properties:
      Tags:
        Tag1: value1
        Tag2: value2
      Auth:
        Authorizers:
          LambdaAuth:
            FunctionArn: !GetAtt MyAuthFn.Arn
            AuthorizerPayloadFormatVersion: 1.0
        DefaultAuthorizer: null

The transformed template shows the following section where /specified shows the authorizer since we explicitly set authorizer in Lambda event source while /default doesn't have anything related to authorizer.

"paths": {
      "/specified": {
       "get": {
        "x-amazon-apigateway-integration": {
         "httpMethod": "POST",
         "type": "aws_proxy",
         "uri": {
          "Fn::Sub": "arn:${AWS::Partition}:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${HttpApiFunction.Arn}/invocations"
         },
         "payloadFormatVersion": "2.0"
        },
        "security": [
         {
          "LambdaAuth": []
         }
        ],
        "responses": {}
       }
      },
      "/default": {
       "post": {
        "x-amazon-apigateway-integration": {
         "httpMethod": "POST",
         "type": "aws_proxy",
         "uri": {
          "Fn::Sub": "arn:${AWS::Partition}:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${HttpApiFunction.Arn}/invocations"
         },
         "payloadFormatVersion": "2.0"
        },
        "responses": {}
       }
      }
     },

@xazhao xazhao closed this Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants