I have a CloudFront distribution abcd1234.cloudfront.net and I've added a custom domain of mysite.com to the distribution.
The CloudFront distribution's origin: aaabbbccc.execute-api.us-east-1.amazonaws.com
When I load the page mysite.com/hello/world, CloudFront is then consuming API Gateway aaabbbccc.execute-api.us-east-1.amazonaws.com/prod/{proxy+}
the API Gateway path endpoint is invoking a Lambda Function that calls a function like getPageContent(customDomainName, pagePath) which should be mysite.com and /hello/world respectively.
However, inside that function, the Host header that eventually makes it into the function's event.headers.Host value is never the custom domain. Instead, the Host header is always aaabbbccc.execute-api.us-east-1.amazonaws.com.
I want headers.Host to equal mysite.com (or another header to show that the request comes from mysite.com, but no matter what I do, the Host value is always just the origin url.
Edit: I tried whitelisting Host and it caused the site to break completely, with the error about not being able to reach the CloudFront distribution.
Related
I have a website called oldcompany.com. Our product name changed, and I would like to use Azure Application Gateway in front of the website, in order to rewrite the URL, i.e. access the website using the newcompany.com hostname.
There is a feature of Azure Application Gateway, called rewrite rules, that allows to modify request and response headers, documented here: https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/application-gateway/rewrite-http-headers-url.md#rewrite-http-headers-and-url-with-application-gateway. The reason I want to use this feature is that it allows specifying complex conditions to rewrite a header. So I don't want to be using the Override with new host name switch on the HTTP setting, but rather overwrite the Host header of all requests going through the application gateway.
I have defined:
the listener to listen on HTTPS, port 443, hostname newcompany.com
the backend pool pointing to oldcompany.com
the rule binding the listener to the backend pool
With this configuration only, accessing https://newcompany.com results in Azure Application Gateway's 502 error page, which is expected, because the Host header in the request is still newcompany.com, which is not a virtual host recognized by the server (which is only serving requests for oldcompany.com).
So, in order to set the Host header, I have configured a rewrite ruleset associated to my routing rule. This ruleset has a rule that changes the request's Host header to oldcompany.com.
However, I still get the same 502 error page when accessing https://newcompany.com. I have pulled the request from my application gateway's access logs, and the request shows the following fields:
host_s: oldcompany.com
originalHost_s: newcompany.com
httpStatus_d: 502
which seems like the correct values for the original and rewritten hosts.
What am I missing to make this work?
Scenario: Want to access content of xyz.example.com from mysubdomain.example.com (using Fetch or XMLHttpRequest).
But CORS is configured in such a way that when ORIGIN(in request header) is "example.com" then only xyz.example.com supplies ACCESS-CONTROL-ALLOW-ORIGIN (with value example.com) and thus able to read its content. But by-default when I am making request from mysubdomain.example.com then origin is set to mysubdomain.example.com and thus not able to read contents of xyz.example.com.
Also all communication is on http only(since port difference also matters).
I am trying to use document.domain="example.com" to change my origin to example.com but it is not changing. How to access resource from other sub-domain in this scenario ?
(I am not having access to change server side code on xyz.example.com)
I have a lambda function being executed by an API gateway. I have cloudfront pointing traffic to the API gateway endpoint.
How do I access the host/domain the client is on in my lambda function?
Can I move the Host header to X-Forwarded-Host?
e.g.
abc.com (cloudfront) -> API gateway -> lambda (Host: abc.com)
In order to propagate Host header through Cloudfront and API Gateway, follow these steps:
Configure Cloudfront to forward Host header
Step-by-step guide
Key points:
Choose the Behaviors tab, and then choose the path that you want to forward the Host header to.
Choose Edit.
Under Cache key and origin requests, confirm that Legacy cache settings is selected. If it's not selected, then follow the steps in the preceding section to create a cache policy. If Legacy cache settings is selected, then complete the following:
For Headers, select Include the following headers.
From the Add header dropdown list, select Host.
Configure API Gateway request to relay Host header
Detailed docs here
Key point:
Edit your API Gateway resource(s) and for each method you need the Host header edit the Method Request by adding Host header in the HTTP Request Headers list.
You can also move the Host header to X-Forwarded-Host using a Cloudfront function but you would still need to follow the steps above to propagate X-Forwarded-Host header. You can try this out starting with this sample function.
I am using various domain aliases through a CDN and I would like to return slightly different results depending on the domain alias. Is there a way to identify the domain of the current URL in Ruby?
For example, the origin URL of my website is non-cdn.herokuapp.com. There is a CDN which is caching that origin URL at 123.cloudfront.net. There are 2 custom domains which are using CNAMEs to point to that CDN URL, cdn-url1.com and cdn-url2.com. When someone visits cdn-url1.com, request.host returns non-cdn.herokuapp.com rather than cdn-url1.com.
I know that I can return the true domain via Javascript, but can I determine it in Ruby?
Amazon Cloudfront is not forwarding the host header to the origin. Here is how to fix it:
Note: This resolution applies to origins other than an Amazon Simple
Storage Service (Amazon S3) bucket. If you're using an Amazon S3
origin, avoid whitelisting the host header. For more information, see
Selecting the Headers to Base Caching On.
Open the Amazon CloudFront console, and then choose your distribution.
Choose the Behaviors view, and then choose the path you are using.
Choose Edit.
For Cache Based on Selected Request Headers, choose Whitelist.
Under Whitelist Headers, choose Host from the column on the left, and then choose Add.
Choose Yes, Edit.
https://aws.amazon.com/premiumsupport/knowledge-center/configure-cloudfront-to-forward-headers/
Using the routing rules as mentioned here: Set up DNS based URL forwarding in Amazon Route53
<RoutingRules>
<RoutingRule>
<Redirect>
<Protocol>https</Protocol>
<HostName>dota2.becomethegamer.com</HostName>
<HttpRedirectCode>301</HttpRedirectCode>
</Redirect>
</RoutingRule>
</RoutingRules>
I am able to see that http://becomethegamer.com properly redirect to https://dota2.becomethegamer.com but https://becomethegamer.com times out.
I thought it was the Protocol piece but realized that's the outbound rather than inbound.
This is in a bucked named becomethegamer.com and in Route 53 becomethegamer.com is an alias with the target as that bucket.
What could be causing https to not redirect?
No, it's this:
The website endpoints do not support https.
http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteEndpoints.html
You can't redirect an https request without speaking https, and additionally, you need an SSL certificate that's valid for the hostname.
You can still do exactly what you're trying to do, but you'll need to use CloudFront in front and S3 in the back. Your S3 redirection configuration stays the same, but you'll create a CloudFront distribution, configure your domain name as an alternative domain name there, load your SSL cert into CloudFront, use the bucket-name.s3-website-xx-xxxx-xx.amazonaws.com web site endpoint (from the S3 console) as the Origin server, and point Route 53 to CloudFront instead of S3.
http://docs.aws.amazon.com/gettingstarted/latest/swh/getting-started-create-cfdist.html