If I am using CloudFlare for SaaS where I have an arbitrary number of clients using custom hostnames, how do I determine on the client what is being requested?
For instance, if the fallback URL is a wild carded "customers.example.com"and there are 2 customers, where one is using a custom hostname, how do I determine what is being requested?
URL requested for customer 1 (no custom hostname): customer1.customers.example.com
URL requested for customer 2 (with custom hostname): foo.bar.com
What is passed on to the origin in terms of headers? Both of these requests go to customers.example.com, so how do I determine which customer the request is on behalf of? Am I supposed to use CloudFlare Workers? Do I just look at the Host header (does CloudFlare protect against this being injected?)?
Related
My ultimate goal is to have free plan cname content, and premium plan cname content.
For example if someone has a cname of free.example.com set to my website I'd like to show them a specific page, and if premium.example.com I want to show them another page. Finally, I'd like to know if there is a way to add new cnames to my list so that I can have them view a certain page?
Just to make this more understandable this, I want to do something like https://www.gitbook.com/ do with their cnames, and cname serving.
You'll have to use the Host header from the user's request to identify which subdomain or cname they're visiting, and then showing them the desired content. If the subdomain such as free and premium are fixed, you could use Nginx server blocks or Apache virtual hosts to direct the user to specific application or application URI.
Likewise, you can get the Host header with req.hostname in Express. Based on the host, you can route the user to the desired content. You can add as much subdomains or cnames you wish and let your application control the content for the user based on the host. If your DNS host has an API (such as Cloudflare), you can add your subdomains programmatically, or you could do a wildcard subdomain to accept any subdomain.
i make website and use IIS web server
now site run with this 2 address
http://panel.example.com and
i can set Arecord for use HTTP with many custom domain name like this
panel.customdomain.com => a record => serverip(x.x.x.x)
http://panel.customdomain.com work just fine but show error this is not valid in browser(Your connection is not private)
is there any way to use many custom domain with HTTPS address ?
i have some reseller and i dont have fixed list for new domains.
If you have full control of your server you can use Let's Encrypt to get ssl certificate for every domain
OR you can use cloudflare.com and get a free certificate
Hope it helps
I need multiple subdomains to point to individual buckets/subdirectories on Amazon S3 (synched to CloudFront distribution), where I'm hosting some static files.
So that ANY
SUBDOMAINNAME.example.com
automatically points to
s3.amazonaws.com/somebucket/SUBDOMAINNAME
or
somedistributionname.cloudfront.net/SUBDOMAINNAME
Is there a way to accomplish this without running a server for redirection?
Can it be done without changing DNS records for each new subdomain or, if not, adding the DNS rules programmatically?
What is the most efficient way of doing it, in terms of resource usage. (There might be hundreds of subdomains with 100s of daily requests for each)
update: this answer was correct when written, and the techniques described below are still perfectly viable but potentially less desirable since Lambda#Edge can now be used to accomplish this objective, as I explained in my answer to Serving a multitude of static sites from a wildcard domain in AWS.
No, there is no way to do this automatically.
Is there a way to accomplish this without running a server for redirection?
Technically, it isn't redirection that you'd need, to accomplish this. You'd need path rewriting, and that's why the answer to your ultimate question is "no" -- because Route 53 (and DNS in general) can't do anything related to paths.
Route 53 does support wildcard DNS, but that's of limited help without CloudFront and/or S3 supporting a mechanism to put the host header from the HTTP request into the path (which they don't).
Now, this could easily be accomplished in a "zero-touch" mode with a single Route 53 * wildcard entry, a single CloudFront distribution configured for *.example.com, and one or more EC2 instances running HAProxy to do the request path rewriting and proxy the request onward to the S3 bucket. A single line in a basic configuration file would accomplish that request rewrite:
http-request set-path /%[req.hdr(host)]%[path]
Then you'd need the proxy to send the the actual bucket endpoint hostname to S3, instead of the hostname supplied by the browser:
http-request set-header Host example-bucket.s3.amazonaws.com
The proxy would send the modified request to S3, return S3's response to CloudFront, which would return the response to the browser.
However, if you don't want to take this approach, since a server would be required, then the alternative solution looks like this:
Configure a CloudFront distribution for each subdomain, setting the alternate domain name for the distribution to match the specific subdomain.
Configure the Origin for each subdomain's distribution to point to the same bucket, setting the origin path to /one-specific-subdomain.example.com. CloudFront will change a request for GET /images/funny-cat.jpg HTTP/1.1 to GET /one-specific-subdomain.example.com/images/funny-cat.jpg HTTP/1.1 before sending the request to S3, resulting in the behavior you described. (This is the same net result as the behavior I described for HAProxy, but it is static, not dynamic, hence one distribution per subdomain; in neither case would this be a "redirect" -- so the address bar would not change).
Configure an A-record Alias in Route 53 for each subdomain, pointing to the subdomain's specific CloudFront distribution.
This can all be done programmatically through the APIs, using any one of the the SDKs, or using aws-cli, which is a very simple way to test, prototype, and script such things without writing much code. CloudFront and Route 53 are both fully automation-friendly.
Note that there is no significant disadvantage to each site using its own CloudFront distribution, because your hit ratio will be no different, and distributions do not have a separate charge -- only request and bandwidth charges.
Note also that CloudFront has a default limit of 200 distributions per AWS account but this is a soft limit that can be increased by sending a request to AWS support.
Since Lambda#edge this can be done with a lambda function triggered by the Cloud Front "Viewer Request" event.
Here is an example of such a Lambda function where a request like foo.example.com/index.html will return the file /foo/index.html from your origin.
You will need a CF distribution with the CNAME *.example.com, and an A record "*.example.com" pointing to it
exports.handler = (event, context, callback) => {
const request = event.Records[0].cf.request;
const subdomain = getSubdomain(request);
if (subdomain) {
request.uri = '/' + subdomain + request.uri;
}
callback(null, request);
};
function getSubdomain(request) {
const hostItem = request.headers.host.find(item => item.key === 'Host');
const reg = /(?:(.*?)\.)[^.]*\.[^.]*$/;
const [_, subdomain] = hostItem.value.match(reg) || [];
return subdomain;
}
As for the costs take a look at lambda pricing. At current pricing is 0.913$ per million requests
A wildcard works on S3. I just put an A record * that points to an IP and it worked.
I'm using an S3 bucket to host a static site, and CloudFlare as a CDN.
I'm noticing a large amount of POST requests (seems like spamming attempts), and I'm trying to block them so that I don't have to pay for that traffic.
Is there a way to block all POST requests on Bucket Policy (that would be the best choice probably)? Perhaps a way to block POST requests on CloudFlare?
CloudFlare has a firewall app you can use to whitelist or blacklist IPs, IP ranges or countries. There doesn't seem to be a way to set rules based on HTTP request type so see if you can blacklist the IP addresses instead.
Check if you have anything listed already on the Threat Control dashboard. In theory it should already challenge suspicious requests.
I have a wildcard certificate for our domain. *.domain.com
We host multiple sites on our one server using host headers with subdomains. In this specific case lets use site1.domain.com the site has a https binding on the hostname with the wildcard ssl cert.
for marketing reasons we want to rename the sites URL / Name. for example awesomewebsite.com
But for hosting and ssl certificate reasons we cant simply change the host headers on the site.
So my question. Is there a way for me to make awesomewebsite.com an alias tohttps://site1.domain.com so that the user can operate and use the site as if it was hosted at awesomewebsite.com and for security reasons all requests are actually sent to https://site1.domain.com
I have both the domains with 'dyndns.org' I know they offer some added services. Not sure if that will be of any user to me?
Also if I can obtain this are there any security concerns or other issues which might be introduced.
When using webhop feature in dyndns.org i get the following error:
Refused to display 'https://site1.domain.com/Account/Login?ReturnUrl=%2F' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'
So my question. Is there a way for me to make awesomewebsite.com an alias tohttps://site1.domain.com so that the user can operate and use the site as if it was hosted at awesomewebsite.com and for security reasons all requests are actually sent to https://site1.domain.com
The validation of the contents of the certificate is done against the name in the URL, which means that your certificate must contain the alias name too.
Never answered properly.
For whom who ends up here during a search:
What you need is a certificate (requested) with alternative names, meaning it contains all the variances you desire of FQDN/DNS names. They do not need to match or belong to the same domain. Also ideal for external name and system internal names (e.g. www.mystuff.com, host123.myhost.com):
https://www.digicert.com/subject-alternative-name.htm