Currently, the SSR Lambda handler uses event.requestContext.domainName to determine the domain name. However, when using the Lambda behind CloudFront and API Gateway, this approach always results in the API Gateway URL being used as the host.
Describe the solution you'd like
To address this, I suggest that the handler should also check for the x-forward-host header, which can be configured in CloudFront. If this header is present, its value should be used as the domain name instead of event.requestContext.domainName.
This change will allow the correct CloudFront domain to be used as the host, providing more flexibility and accuracy in environments where the Lambda function is accessed through CloudFront.
Describe alternatives you've considered
We have considered alternatives, but none provide a satisfactory solution to the problem. Our main issue is that auth-astro uses the request URL, which will not work correctly without this change. Without the ability to use the x-forward-host header, the application continues to receive the API Gateway URL instead of the desired CloudFront domain, causing issues in our setup.
Documentation, Adoption, Migration Strategy
I will open a pull request (PR) to implement this feature and hope it will be merged soon. Once merged, I hope a new version of astro-aws will be released to include this enhancement.
💻
What problem are you trying to solve?
Currently, the SSR Lambda handler uses
event.requestContext.domainNameto determine the domain name. However, when using the Lambda behind CloudFront and API Gateway, this approach always results in the API Gateway URL being used as the host.Describe the solution you'd like
To address this, I suggest that the handler should also check for the
x-forward-hostheader, which can be configured in CloudFront. If this header is present, its value should be used as the domain name instead ofevent.requestContext.domainName.This change will allow the correct CloudFront domain to be used as the host, providing more flexibility and accuracy in environments where the Lambda function is accessed through CloudFront.
Describe alternatives you've considered
We have considered alternatives, but none provide a satisfactory solution to the problem. Our main issue is that auth-astro uses the request URL, which will not work correctly without this change. Without the ability to use the x-forward-host header, the application continues to receive the API Gateway URL instead of the desired CloudFront domain, causing issues in our setup.
Documentation, Adoption, Migration Strategy
I will open a pull request (PR) to implement this feature and hope it will be merged soon. Once merged, I hope a new version of
astro-awswill be released to include this enhancement.