Передача URL-адреса пользовательского домена с облачным фронтом в lambda

Question

У меня есть пользовательский URL домена (my-custom-domain.com), а REST API поддерживает параметры запроса и пути.

https://my -custom-domain.com / hello

https://my -custom-domain.com? Firstparam = abc & secondparam = def

Вызванная лямбда-функция должна возвращать ответ с добавлением некоторых параметров пути / запросана пользовательский URL домена в теле json.В основном другие ресурсы, к которым можно получить доступ.

Пример: https://my -custom-domain.com / hellofromlambda1123

https://my -custom-domain.com? firstparam = abc & secondparam = yourblogpage & pagenumber = 30

Идеальный вариант использования - это разбиение на страницы, где я должен дать предыдущую и следующую ссылки.Как передать пользовательский URL-адрес домена моей лямбде?Я работаю над узлом js 8

В обычном программировании JAVA мы можем добиться этого с помощью HttpServletRequest.getRequestURL ().Какой способ получить пользовательский URL домена.Я включил заголовки для DefaultCacheBehavior.Хост в лямбда-событии дает URL-адрес шлюза API.Есть ли способ получить сопоставление настраиваемого домена внутри лямбды?

Шаблон формирования моего облака для настраиваемого домена выглядит следующим образом

AWSTemplateFormatVersion: '2010-09-09'
Description: Custom domain template

Parameters:
  ServiceName:
    Description: Name of the Service
    Type: String
  DeploymentEnv:
    Default: dev
    Description: The environment this stack is being deployed to.
    Type: String
  CertificateId:
    Description: SSL Certificate Id
    Type: String
  DomainName:
    Description: Name of the custom domain
    Type: String
  HostedZoneId:
    Description: Id of the hosted zone
    Type: String

Resources:
  APIDistribution:
    Type: AWS::CloudFront::Distribution
    Properties:
      DistributionConfig:
        Origins:
        - DomainName:  
            Fn::ImportValue:
              !Sub "InvokeURL-${DeploymentEnv}"
          Id: !Sub 'Custom-Domain-${DeploymentEnv}'
          CustomOriginConfig:
            OriginProtocolPolicy: https-only
            OriginSSLProtocols: [TLSv1.2]
        Enabled: 'true'
        DefaultCacheBehavior:
          AllowedMethods:
          - DELETE
          - GET
          - HEAD
          - OPTIONS
          - PATCH
          - POST
          - PUT
          DefaultTTL: 0
          TargetOriginId: !Sub 'Custom-Domain-${DeploymentEnv}'
          ForwardedValues:
            QueryString: 'true'
            Cookies:
              Forward: none
            Headers:
              - 'Accept'
              - 'api-version'
              - 'Authorization'
          ViewerProtocolPolicy: https-only
        Aliases:
          - !Sub '${DomainName}'
        ViewerCertificate:
          AcmCertificateArn: !Sub '${CertificateId}'
          SslSupportMethod: sni-only
          MinimumProtocolVersion: TLSv1.2_2018
  APIDNSRecord:
    Type: AWS::Route53::RecordSet
    DependsOn: "APIDistribution"
    Properties:
      HostedZoneId: !Sub '${HostedZoneId}'
      Comment: DNS name for the custom distribution.
      Name: !Sub '${DomainName}'
      Type: A
      AliasTarget:
        DNSName: !GetAtt APIDistribution.DomainName
        HostedZoneId: Z2FDTNDATAQYW2
        EvaluateTargetHealth: false
Outputs:
  DomainName: 
    Value: !GetAtt APIDistribution.DomainName

Answer 1

Спасибо @thomasmichaelwallace за указание на мой пост на форуме AWS, который объясняет способ вставки заголовка исходного запроса Host в альтернативный заголовок запроса с использованием триггера Lambda @ Edge Origin Request.Это одно из решений, но для него требуется лямбда-триггер, поэтому есть дополнительные издержки и затраты.Это решение на самом деле касалось дистрибутива CloudFront, который обрабатывает несколько доменных имен, но должен отправить один заголовок Host во внутреннее приложение, одновременно предупреждая приложение о другом заголовке запроса, который я произвольно назвал X-Forwarded-Host.

Существуют альтернативы.

Если дистрибутив CloudFront обрабатывает только одно входящее имя хоста, вы можете просто настроить статический настраиваемый заголовок источника .Они безоговорочно вводятся в запросы CloudFront (и если исходный запросчик устанавливает такой заголовок, он отбрасывается до того, как настроенный заголовок будет введен).Установите X-Forwarded-Host: api.example.com, и он будет введен во все запросы и видим на API Gateway.

Это самое простое решение, и в зависимости от того, что в вопросе, оно должно работать.

Но интуитивно понятныйрешение не работает - вы не можете просто внести в белый список заголовок Host для пересылки к источнику, потому что это не то, что ожидает API-шлюз.

Но там должно бытьспособ заставить его ожидать этот заголовок.

Следующее основано на ряде наблюдений, которые являются точными, независимо, но я не проверял их все вместе.Вот идея:

• использовать развертывание регионального API-шлюза, а не Edge-Optimized.В любом случае вам не нужно оптимизированное по краям развертывание, когда вы используете собственный дистрибутив CloudFront, потому что это увеличивает задержку, отправляя запрос через сеть CloudFront с избыточностью.Это также не будет работать в этой настройке.
• настроить ваш API как настраиваемый домен (для вашего открытого домена)
• , подключив соответствующий сертификат к API-шлюзу, но
• делать, не указывать DNS на назначенное региональное доменное имя, которое дает вам API Gateway;вместо этого
• использует назначенное имя хоста региональной конечной точки в качестве имени домена происхождения в CloudFront
• , в белый список заголовка хоста для переадресации

Этот должен работать, потому что это заставит API Gateway ожидать исходный заголовок Host в сочетании с тем, как CloudFront обрабатывает TLS на внутреннем сервере, когда заголовок Host находится в белом списке для пересылки.

Answer 2

При использовании API Gateway + Lambda с интеграцией Lambda Proxy полученное лямбда-событие включает в себя ключи headers.Host и headers.X-Forwarded-Proto, которые можно объединить для создания полного URL-адреса запроса.

Например, для https://my-custom-domain.com/hellofromlambda1123

{
  "headers": {
    "Host": "my-custom-domain.com"
    "X-Forwarded-Proto": "https"
  }
}