I'm setting up traffic management for a global external HTTP(S) load balancers. I have two backend Cloud Run services, serverless-lb-www-service and serverless-lb-api-service, that I want to serve from the same IP/domain.
I want to configure them like this:
example.com -> serverless-lb-www-service
example.com/api -> serverless-lb-api-service
I can use the simple routing rules to serve traffic semi-expected:
path
backend
/*
serverless-lb-www-service
/api
serverless-lb-api-service
/api/*
serverless-lb-api-service
However, I'm running into an issue where I try to access an endpoint that is not the root API end, like example.com/api/test. I'm always seeing the response I would expect from example.com/api.
I believe it has something to do with my API (running express.js) receiving the path /api when it is instead expecting to serve that route from there just /test. I think I might need to set up a rewrite to remove /api when it hits the API
Any help would be much appreciated. Thanks
update
I can confirm that the requests as logged in the API are all prefixed with /api. I can solve my issue by changing all API route handlers to expect the /api prefix in production environment. However I would still rather do this via a path rewrite so application code is the same in all environments
You can customize the host and path rules. You can follow the steps through this link. It is also using Cloud Run services and might help you with the rewrite path issues.
Note: Just scroll all the way down if the link will not redirect and show the "Customize the host and path rules" steps.
I am giving my services to my users via client.example.com and there are pages like
client.mysite.com/blog
client.mysite.com/blog/content/
client.mysite.com/docs/
etc.
I want to allow users to allow their domains to point to this subdomain.
so they can choose between any of the 1 option below :
client.com -> client.example.com
sub.client.com -> client.example.com
client.com/sub/ -> client.example.com
and pages should work automatically like
client.com/blog -> client.example.com/blog
sub.client.com/blog -> client.example.com/blog
client.com/sub/blog -> client.example.com/blog
Also, I use Elastic Beanstalk in Amazon to deploy my React application with nginx (Docker image ). Before I start I want to know if this is possible.I also don't want to give fixed IP address to my clients, just in case if I lose that IP. How are the big players like blogger.com, wordpress.com etc doing it?
As far as I researched I know cname is possible to allow clients subdomains and we need IP address for named domain. nowhere it mentioned about the folder. And for SSL, I can use LetsEncrypt.
I am OK with anything like CloudFlare / Route53 method.
Cloudflare for SaaS is designed for this use case. You would just go to Cloudflare Dashboard > You Domain (example.com) -> SSL -> Custom Hostnames. Add a fallback hostname to which you client will link to, e.g. ssl.example.com.
Then client then would need to add his or her custom hostname in your app, then link and verify his custom domain by adding a CNAME (pointing to ssl.example.com) and TXT record via his own DNS provider. The verification and issuing a new SSL would take a few minutes, completely handled by Cloudflare and from there on, your clients may access your service via custom hostname (e.g. client.com, sub.client.com, client.com/blog etc.)
If you need to manipulate the HTTP response as it goes through the customer's hostname, it's also possible to route these request through a CLoudflare Worker script (linked to */* — all hostnames/URLs).
Here is an example, of how to create a custom hostname programmatically:
import * as Cloudlfare from "cloudflare-client";
// Initialize custom hostnames client for Cloudlfare
const customHostnames = Cloudflare.customHostnames({
zoneId: process.env.CLOUDFLARE_ZONE_ID,
accessToken: process.env.CLOUDFLARE_API_TOKEN,
});
// Add the client's custom hostname record to Cloudflare
const record = await customHostnames.create(
hostname: "www.client.com",
ssl: {
method: "txt",
type: "dv",
settings: {
min_tls_version: "1.0",
},
}
);
// Fetch the status of the custom hostname
const status = await customHostnames.get(record.id);
// => { id: "xxx", status: "pending", ... } including TXT records
Pricing
CF for SaaS is free for 100 hostnames and $0.10/hostname/mo after (source).
Path-based URL forwarding
If you need to forward HTTP traffic to different endpoints, e.g. www.client.com/* (customer domain) to web.example.com (SaaS endpoint); www.client.com/blog/* to blog.example.com, etc.
You can achieve that by creating a Cloudfalre Worker script with a route handling */* requests (all customer hostnames, and all URL paths), that would look similar to this:
export default {
fetch(req, env, ctx) {
const url = new URL(req.url);
const { pathname, search } = url;
if (url.pathname === "/blog" || url.pathname.startsWith("/blog/")) {
return fetch(`https://blog.example.com${pathname}${search}`, req);
}
return fetch(`https://web.example.com${pathname}${search}`;
}
}
References
https://developers.cloudflare.com/cloudflare-for-saas/
https://github.com/kriasoft/cloudflare-client
https://github.com/kriasoft/cloudflare-starter-kit
The simplest approach to this, which I’ve implemented at scale (10,000+ clients), is to:
DNS
Have your clients create a CNAME record to either a specific client.example.com or general clients.example.com. This applies to both root (set the ALIAS record instead) and subdomains—an IP address is not required, nor recommended as it does not scale.
Create a database entry that registers/links that explicitly links their domain/subdomain to their account.
Have logic in the backend controller will that associates the hostname in the request to a specific client (security measure) to serve relevant content.
The above fulfills the first two use cases—it allows the client to link a root domain or subdomain to your service.
To achieve the third use case, you could allow the client to specify an arbitrary root path for your service to run within. If the client chooses this, you also need to handle redirects to other services that they have on their domain. This is a lot of responsibility for your app, however.
You could just leverage their registrar, most registrars have the ability to do path redirects—this is the simplest approach that requires the least amount of responsibility/maintenance on your end.
I also recommend having an option for redirecting all entry points (ie: root domain, subdomain, root domain+path, subdomain+path) to a primary entry point (ie: root domain + path), for SEO purposes.
Note: You may also use a service, such as wwwizer, that redirects to the www specified if the ALIAS option on the root domain of your client isn't available.
SSL
I recommend using Let's Encrypt's ACMEv2 API to enable SSL for any domain that is setup on your service. There are libraries available that you should be able.
What is worth mentioning is the challenge — which can occur via DNS or HTTP. When the library you decide on makes a request for a new certificate Let's Encrypt will respond by making a request to ensure that you control the domain (by checking DNS record for a predetermined unique hash) or that you control the server it points to (by checking HTTP path for a predetermined unique hash). What that means is that you need to ensure that your client either includes a hash in their DNS that you specify or you expose a route that adheres to the ACME v2 challenge response protocol (handled by the library you choose).
Here is an example library that you could use if the service you are building is based on python, which supports all features mentioned above and also includes a cli: https://github.com/komuw/sewer .
References
https://help.ns1.com/hc/en-us/articles/360017511293-What-is-the-difference-between-CNAME-and-ALIAS-records-
https://letsencrypt.org/docs/client-options/
https://datatracker.ietf.org/doc/html/rfc8555
http://wwwizer.com
I think what you are asking is how to have the client have their own domain, which they own, have a subdomain which points to your website, with a matching certificate somehow. But just from a security standpoint there is no safe way to do this IMO. Here are the ways off the top of my head you can do this:
You Manage DNS of Subdomain
Your customer could create a NS record to a public Route53 distribution which you own. Then that subdomain would effectively be yours, and you can create DNS records in their subdomain, and certificates in ACM which you can use in a Cloudfront Distribution. You can have multiple FQDN in the one certificate so you won't have to have multiple distributions. You will need to add the domains to the aliases in your distribution as well.
Client Manages own DNS but you tell them what to do
I'm not sure this works as I haven't tried it, but in the DNS validation of a ACM certificate you can see the records you need to create, you would tell the client the CNAME record which they need to create for AWS to issue a certificate for the given domain i.e. sub.client.com, and they would also need to create CNAMEs to point to your website. This way the client still manages their own DNS.
Import Certificate
You could get your client to create a cert for you can then you could import it. They would also need to create the CNAME records to point to your website. And again they would need to create a CNAME to point to your site. Probably least secure, and certs will require manual rotation.
Cloudfront
Your client can use your website as an origin in their own Cloudfront Distribution, bit hacky but would work. I don't think this scales with growing customers.
Summary
IMO I don't like any of those solutions, they are all messy, most likely non-compliant with security standards, and hard to automate if at all. Not to say there aren't situations where you might do this. I would suggest you create subdomains for your own domain, or otherwise consider yourself a hosting company and then you would own/manage your client's domains on their behalf then this easier. But IMO it does not make sense to own a domain, and then give out control to it, or transfer certificates. You'll run into trouble with customers who need to hold certain certifications, or need you to hold those, such as SOC2 for example.
Is there a way to redirect the incoming URL to another URL?
EX - when user hits https://www.website1.com, user should be redirected to https://www.website2.com
CloudFoundry itself does not provide a way to redirect arbitrary requests prior to requests hitting an application (i.e. at the Gorouter layer).
You have some options though:
Perform redirects on your load balancer. If you need to redirect the request as early as possible, doing it on your load balancers would be the earliest possible place. This is good for example if you want to redirect all requests from HTTP to HTTPS. It does assume that your load balancer will allow this, and not all do.
You can redirect from an application. So in your example, the application to which you have mapped the route www.website1.com would be listening and issue the redirect response to send requests to www.website2.com.
This app could be something as simple as an nginx.conf pushed using the Nginx Buildpack, or you could develop a custom application to issue the redirects. The beauty of this is that you can map any number of routes (including wildcards) to the app and a single Nginx server, configured correctly, could issue redirects for all of them. If you are redirecting a lot of separate URLs to one central URL, this works well.
If you have an existing application on www.website1.com and cannot replace it with an Nginx app to do the redirects, you could modify your custom application to perform the redirects. You don't have to use Nginx, it is just a convenient and very low overhead way to do redirects.
You could use a route service. Route Services are able to filter requests and so you could use one to intercept requests and issue redirects for certain routes/domains.
A route service can make some sense if you have complicated routing logic or if you have many applications to which you need to apply the logic. The reason is that a route service requires a custom application to be the route service. So if you have one application and you're trying to redirect requests for that one application to somewhere else, it doesn't make sense to add a second application into the mix just to perform some redirects. Now, if you have 500 applications and they all need some sort of redirect logic, it could make a little more sense to use a route service.
I currently have an app that works with both www.domain.com and domain.com. Considering that this seems to be bad for SEO, I want it to always redirect to the naked domain.
My app works in this way:
Server: Google Cloud Platform (App engine)
App: Django
Domain provider: Godaddy
As I have researched the redirection can be done from any of these 3 options. So I want to ask: What is the best option and why?
I tested to do the redirection with GoDaddy on App Engine (An A record for www pointing to #) but when I set my custom domain in App Engine, I noticed that for the www.domain a C Record pointed to ghs.googlehosted.com setting was required in the app engine panel, I omitted that in order to do the redirection in GoDaddy, but the app wouldn't load when visiting from www.domain, a 404 error appeared (Also tried by omitting the addition of the www.domain altogether in app engine settings) So I wasn't able to accomplish this in the same fashion than an app that is hosted in a single server.
I think the easiest way would be to handle this inside the app itself like this site mentions
For example:
About www.abc.com , and en.abc.com
I want to know how to configure the CDN or somethings, make the CDN only works in www.abc.com,
for en.abc.com don't works.
I am using aliyun.com as my cdn provider.
How about the NGINX or Django or Domain or CDN settings?
CDN systems always 'only' work on their configured hostnames. Basically, a CDN is a reverse proxy with a set of rules on it. For any request coming in, it has to know
where to fetch the content from
which additional logic to apply to the content when delivering it
If you want to use a different hostname on the CDN, you will have to make the CDN work, all other components in your web site delivery will not be reached if the CDN configuration doesn't proxy the request to your web server.
I am not familiar with aliyun.com specifically, but there might be a chance to have them set up a wildcard/regex hostname (like *.example.com). You will have to get suport from aliyun to understand if this is possible.