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

does not handle list of distributions #7

Open
hmoffatt opened this issue Oct 7, 2019 · 3 comments
Open

does not handle list of distributions #7

hmoffatt opened this issue Oct 7, 2019 · 3 comments

Comments

@hmoffatt
Copy link

hmoffatt commented Oct 7, 2019

If functions.<function>.lambdaAtEdge is a list of distributions, rather than a single distribution, the plugin does not handle it;

functions:
  lambda:
    handler: handlers.onViewerRequest
    lambdaAtEdge:
      - distribution: 'WebsiteDistribution'
        eventType: 'viewer-request'
        pathPattern: '*'

Results in:

$ sls offline start
Serverless: CloudFront Offline listening on port 8080
Serverless: Cache directory: file:///tmp/edge-lambda
Serverless: Files directory: file:///tmp/edge-lambda

Serverless: Lambdas for path pattern *: 
Serverless: viewer-request => 
Serverless: origin-request => 
Serverless: origin-response => 
Serverless: viewer-response => 

I am attaching the same Lambda to multiple different CloudFront paths (cache behaviours) so I need to list them all for each function.

@mattstrom
Copy link
Collaborator

I can correct the inability to define lambdaAtEdge as an array.

That begs the question, though, which you distribution would you expect the offline server to mock? In the live scenario, different distributions would be bound to different domains whereas with the offline server it only has localhost to bind to. Overlaying path patterns from separate distributions is more complexity than I wish to introduce.

@hmoffatt
Copy link
Author

hmoffatt commented Oct 7, 2019

That is a fair point. I think it's an acceptable limitation.

In my case I am using a single distribution but it has multiple cache behaviours (different origins and different caching settings for different paths), and CloudFront requires the lambdas to be attached to each, they are not shared.

functions:
  headers:
    handler: handler.headers
    description: Set response headers
    memorySize: 128
    timeout: 1
    lambdaAtEdge:
      - distribution: WebsiteDistribution
        eventType: viewer-response
      - distribution: WebsiteDistribution
        eventType: viewer-response
        pathPattern: 'static/*'
      - distribution: WebsiteDistribution
        eventType: viewer-response
        pathPattern: 'locate/*'

resources:
  Resources:
    WebsiteDistribution:
      Type: AWS::CloudFront::Distribution
      Properties:
        DistributionConfig:
          CacheBehaviors:
            - 
              PathPattern: 'static/*'
              TargetOriginId: S3Origin
              ViewerProtocolPolicy: redirect-to-https
              MinTTL: 604800
              DefaultTTL: 604800
              MaxTTL: 31536000
              Compress: true
              ForwardedValues:
                QueryString: true
                QueryStringCacheKeys:
                  - v
                Cookies:
                  Forward: 'none'
            - 
              PathPattern: 'locate/*'
              TargetOriginId: DbLocator
              ViewerProtocolPolicy: redirect-to-https
              ForwardedValues:
                QueryString: false
                Cookies:
                  Forward: 'none'

          DefaultCacheBehavior:
            TargetOriginId: S3Origin
            ViewerProtocolPolicy: redirect-to-https
            MinTTL: 604800
            DefaultTTL: 604800
            MaxTTL: 31536000
            Compress: true
            ForwardedValues:
              QueryString: true
              QueryStringCacheKeys:
                - v
              Cookies:
                Forward: 'none'

@tstackhouse
Copy link

I'm in a similar situation where I'm using the native cloudFront events to define my edge handlers, and attaching Origin information so they match up with my Resources stanza, like so:

  originRequest:
    handler: functions/origin-request.handler
    events:
      - cloudFront:
          eventType: origin-request
          isDefaultOrigin: true
          origin:
            DomainName: ${self:custom.webAppBucket}.s3.amazonaws.com

Would it be possible for this plugin to use the natives events form of configuration rather than requiring its own special syntax?

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

No branches or pull requests

3 participants