I have a Node.js app that serves http requests. Users can signup, create an account and when they do, I generate a subdomain for them to use. eg username.example.com. This is fairly straight forward to do and can be served over ssl using a single certificate.
I would like to give the option for the user to use their own domain. From Node.js this isn't too difficult either. I can check the hostname and look up the account details from there.
I'm struggling to work out how to generate ssl's for these custom domains though.
Right now, my app runs on Heroku, but I also have a staging build on Google's App Engine, so I don't deal with the web server directly. In fact, I don't even know what it is, it could be Nginx or Apache.
To keep the conversation focused, let's stay I want to stick to app engine. When a user adds their own domain, I store it in the database. How would I auto generate an SSL for this?
I thought of general steps for this, but there is one showstopper which I'm not sure it is possible to workaround. The steps will be:
Map the user's domain to your application and configure the DNS records. You can do that with the gcloud commands: steps and general description outlined in this Mapping Custom Domains docs page (notice that you can switch between Console and GCloud in the boxes). There is also a possibility of doing that within the Cloud Console, however as you've mentioned you're interested in the programmatic approach. If you prefer to configure the custom domain from the API, the same functionality exists in App Engine Admin API with its REST resource for domain mappings.
Possible showstopper (source: Mapping Custom Domains) :
Verify that you are the owner of your domain through Webmaster Central
After that, App Engine provisions a managed certificate and then handles renewing/revoking it. Securing Custom Domains with SSL is still in beta, but it offers the functionality that you need.
Related
This is more of a general question about. I have a website running as an Azure App Service. I configured a custom domain so that you are able to call it by my-site-name.com.
As the request of customers kept growing and each customer has specific demands, I was wondering if it is possible to have a subdomain for each customer. For example, client1.my-site-name.com and client2.my-site-name.com.
Is it possible to do all of this within a single App Service or do I need to set up an Azure App Service for each subdomain?
The reason behind my question is, that it would be quite expensive to have an App Service for each individual customer.
You should also consider just adding a wildcard custom domain entry. This is an older blog post, but it outlines Azure WebApp support for Wildcards:
https://azure.microsoft.com/en-us/blog/azure-websites-and-wildcard-domains/
This would mean that *.my-site-name.com traffic goes to your single Web App. Then it is up to the logic of your webapp to determine which client it is by inspecting the hostname of the request (client1.my-site.name.com) and taking the appropriate action to customize the response to that client.
Using a wildcard eliminates the need to add a specific custom subdomain mapping for each client.
It should be possible. Within your app service, if you go to the settings for that service, there is a Custom domains option, select it.
Within there you can then map your subdomains to this service, and it allows you to do it multiple times. You just need to validate and set it up with the A record or CNAME and own the domain. Additionally, you should be able to add SSL Bindings for each.
Here are some documentation on it, I don't believe this documentation handles your exact use case but it does touch on the custom domain portion and should provide additional support.
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain
https://blogs.msdn.microsoft.com/waws/2014/10/01/mapping-a-custom-subdomain-to-an-azure-website/
Let me know if you need more
This seems more like a domain management issue than an azure specific issue. You have already decided to have different sub domains to each customer. That, by definition, means each sub domain needs individual server space. That in turn would mean, an app service for each customer.
So, the answer is what you already have. Have an app service (essentially web server) for each customer via sub domain.
In your position, I would consider some alternatives.
Rebuild your app to work with some form of login system, so clients login and get themselves a separate view.
Alternatively, go with sub folders instead of custom domains. something like, domain.com/client1, domain.com/client2 and so on.
I'm migrating a complete infrastructure over to Azure; it's been slow going as there's so much to learn and for every two steps forward, there seems to be one step back.
After what seems like an eternity, I think I've got it all sorted with one exception.
The architecture is as follows:
Azure Traffic Manager ==> 2 Azure Application Gateways (geo separated) ==> Azure App Service
A custom domain is used for the traffic manager and the gateways are listening for the same domain and, when the route matches, passing on the requests down to the app service.
The actual app itself is a ASP.NET MVC application and it uses forms authentication; and this is where the challenge happens.
When navigating to the public address: client.domain.com and hitting the website, it determines that the user is not authenticated and sends the browser to the login page... so far so good but, rather than using client.domain.com/login it uses the web-server dns name, so client.azurewebsites.com/login
How do I go about changing the behaviour so that it uses the external DNS name rather than the website name?
I can't setup custom domains on the app service as the only route into the site is via the gateway as this is also the firewall.
Is there some Web Config setting I can make? I'm looking at the outbound rewrite rules but these seem to only work on tags rather than 302 redirects.
Any thoughts would be most welcome.
You need to setup custom dns names on your webapp (you can use TXT record to verify dns name, so i dont see a reason why you can add it to the webapp). or you can alter the code.
In order to solve this problem, I had to make a code change to the web app itself. Not ideal but it worked.
What I had to do was to extend the code that redirects an unauthenticated request to the login page by sniffing for the X-Original-Host HTTP Header that the App Gateway forwards on. This contains the public facing DNS name. If the header is present and it is on a pre-approved white-list (so as to prevent any hijacking), then redirect the user to the login page for this domain, rather than the one the server is listening on directly (so use client.domain.com rather than client.azurewebsites.com)
when adding a custom domain to Azure app service, the system always trying to validate your custom domain, but this is very annoying for my case.
i have a CDN service which i have put my www. sub domain on it, and the now i am going to move my website to azure app service
actually i have the website up running already on app service, and the only thing i need to do is point the origin server address to app service in CDN setting
but, i need to set up a custom domain on app service for www. otherwise it won't load.
so the worst thing is, when i try to add the www record as custom domain, it validates if the record is really pointed to app service, which is definitely not possible because if i switch the domain really to app service,
first, i can not guarantee all user will get the dns change in same
time
second, then i need to switch www back to CDN after the
validation, then during this period, my app will work without cdn,
which will be a problem also
so is there anyway to add a custom domain without validation.
this is really stupid, i have to say
maybe i am stupid
found the way in office MS documents
here is the link
https://learn.microsoft.com/en-us/azure/app-service-web/app-service-custom-domain-name-migrate
you can set up a txt verification recond to pass the verification
I have a app which is a website builder. Lets say the app is on a azure webrole and its domain is called www.myapp.com.
I want to offer a service where users can use their custom domain with my app. So User 1 has a domain called ww.user1.com, user2 has www.user2.com etc. Whenever someone types www.user1.com, I want them to be able to see come to my my app ie www.myapp.com, with the browser still showing www.user1.com. You can assume I have complete access to the DNS and nameservers of these custom domains. I just need to understand how to configure this in azure.
Not really, as it was on SSL binding of multiple custom domains on a single cloud. I was trying to figure out how to have one app on a cloud service where content changes as per custom domain end user has used to navigate to the website. Turns out its easy, all that is required is cname config and listening to host_header on server side aspx page_init –
I currently have a VPS with another provider. On that VPS, I have IIS running with multiple app pools and web sites. I would like to get out of the "server management business", so it would seem that Azure Web Sites (Reserved) would be a great fit. I'm able to get the Azure Web Sites set up, including the custom domain piece. The problem that I can't seem to figure out is how to get the same URLs and behavior that I currently have on my VPS.
For example, I have URLs that look like this right now:
www.foo.com/bar
www.foo.com/baz
wildcard.foo.com/bla
I can't find a way to mimic that in Azure.
Things I've thought of/tried:
Go with one Azure Web Site and have separate virtual directories/app pools in Azure, but googling tells me that isn't supported.
Create 3 Azure Web Sites, one for each of the above. The problem there as I see it is I would need to change to use bar.foo.com, baz.foo.com, and bla.foo.com/wildcard (i.e. lose wildcard subdomain mapping and rework things to have a custom route at the end).
Maybe have one Azure Web Site with a rewrite URL? The problem I think I'd run into there is that it all runs in one app pool, so deploying one piece will affect all 3, and obviously a fault in one app would impact the other 2.
Has anyone else gone down this path and solved it? If the answer is spin up a virtual server, I'll probably just stay where I'm at.
Considering www.foo.com/bar, www.foo.com/baz and wildcard.foo.com/bla are 3 independent web applications that share a domain (foo.com):
Create a Windows Azure Website for each web application. You don't necessarily need to assign custom domain names to them.
Create another, separate website and assign to it the *.foo.com domain using an A record. Refer to Configuring a custom domain name for a Windows Azure web site for instructions. As documented, "With an A record, you map a domain (e.g., contoso.com or www.contoso.com) or a wildcard domain (e.g., *.contoso.com) to the single public IP address of a deployment within a Windows Azure web site. The main benefit of this approach over using CNAMEs is that you can map root domains (e.g., contoso.com) and wildcard domains (e.g., *.contoso.com), in addition to subdomains (e.g., www.contoso.com)."
In this "master" website, set up URL redirection (possibly with status code 307 Temporary Redirect) so that requests go to the appropriate applications.
Alternatively, to avoid the delay of the additional request caused by the redirection, set up the "master" website as a reverse proxy that transparently forwards the request to the "inner" web application and sends the response back to the user.
As yet another alternative, use a custom DNS service to do the routing at the DNS layer.
This way, each web application is independent and you solve the issue of routing requests to the appropriate application.