I am creating my first MEAN2 app, but I stuck in mid. My site required one front-end (mysite.com) and one back-end(admin.mysite.com) to manage content. In future I would like to have a unique URL (*.mysite.com) for all the uses who will register at my site, for which there would not be a any directory in real. How could I acchieve it in a best way. To be more clear my requirement is -
mysite.com (original site)
admin.mysite.com (a sub-domain to be managed from same server.js file)
*.mysite.com (based on request host)
Note: I have created site using angular-cli are my structure is like below
-mysite(angular 4 app)
-admin(another angular 4 app)
-server.js
This problem is not specific to node.js. However, in order to setup a domain successfully for your web app, you'll need 2 things:
Web Server
This will manage for you virtual hostnames etc. I would advise you to look at setting up nginx as a reverse proxy in front of your node app.
Domain provider
This will actually allow you to publicly use the domain *.mysite.com. Then you will have to setup a DNS Record, generally an A record, to point at your server IP Address.
This is very high level :) but should be enough to get you started.
EDIT
If you want to test locally just setup nginx with a test server name to proxy_pass to your local nodejs app (i.e. http://localhost:3000) and create a host entry in your hosts file for that hostname.
Related
I have a web server using cpanel and I would like to use a custom domain on one folder for an api. So if I created a folder called api in the public_html folder then the path to that folder would be www.example.co.uk/api/(some php file). How could I change it so the folder would become a custom domain of api.example.co.uk/api/(some php file).
I have looked at a few options but don't really know the best way. I have tried to add a htaccsess file to the api folder and then create a rewrite rule to rewrite the www to api.
I also then looked at creating sub domains with the path to the api folder.
I have read that creating a A record on the server could work but I'm not quite sure how to do this. I know it can be done as most apis use some custom domain like facebooks graph api. (i.e https://graph.facebook.com/youtube/)
This will depend on if you have access to make DNS records for your root domain, example.co.uk. For example right now www. is a CNAME or A record (depends on how your web server is set up), that resolves to the address of your web server. If you made an identical record but named it api. (api. IN A ip-of-webserver), then api.example.co.uk would do the same thing that www.example.co.uk does. This is kind of pointless if they go to the same web server though, the /api/ part of the route makes it clear enough that the routes are for the api. What subdomains like facebook's are doing are pointing to a completely different application, and different web servers. For example, a company may have domains like mail.company.com, portal.company.com, sso.company.com, that all resolve to the address of different web servers for the different apps they have, but in this case it sounds like you are running one web server which is fine, you can have one web server be the api as well as serve the website.
I want to move some websites from server 1 to server 2.
My clients have A records pointing to the IP address of server 1. Without updating their DNS records, how can I automatically forward request for those domains from server 1 to server 2?
Thanks
Graham
This image is from an article regarding Exchange, but the IIS settings are relevant.
You can redirect at the HTTP level by specifying a URL redirect in IIS's HTTP Redirect settings:-
However, for this approach to work you will need a new domain for your sites. e.g. if the A record resolves www.example.com to Server 1 you will need to redirect to another URL (e.g. www.example.edu) that already resolves to Server 2.
Another option is to setup a reverse proxy using IIS on Server 1:
Today there was a question in the IIS.net Forums asking how to expose two different Internet sites from another site making them look like if they were subdirectories in the main site.
So for example the goal was to have a site: www.site.com expose a www.site.com/company1 and a www.site.com/company2 and have the content from www.company1.com served for the first one and www.company2.com served in the second one
So slightly different requirements (the article only wants a subdirectory rather than the whole site), but the same concept will apply.
I have a web app that is composed from 2 apps:
- a simple PHP presentation site that handle account creation
- an API ran by a Tomcat server
I have the apache setup to server at mydomain.com the PHP, but I want to server at mydomain.com/api the Java app that runs on 127.0.0.1:8080.
I know how to do this using api.mydomain.com, but I have single site SSL certificate that does not cover subdomains, this is why I need to do this by path.
Is this possible?
I guess you are looking for a reverse proxy.
See: http://www.linuxjournal.com/content/protect-your-ports-reverse-proxy?page=0,0
Edit: I think below two links are closer to your use case
https://stackoverflow.com/a/1252993/115896
http://blog.lundscape.com/2009/05/configure-a-reverse-proxy-with-apache/
Our company has two sites
www.mysite.com -- Wordpress site
www.mysite.com/portal -- asp.net mvc site
We want to move the wordpress site (www.mysite.com) to Azure and the other site stays local. We need to url stay the same. How can we achieve this?
Since you state that you need the URL to stay the same, this can be achieved through a reverse proxy. You would set up a web server (typically nginx or IIS) answering on www.mysite.com.
This web server would have reverse proxy rules to forward requests for /portal to your on-premises server (in a given, non-public IP and port) and all other requests to another web server running WordPress (on the same server/cluster that runs the reverse proxy, or a separate one), also with a given IP and port.
All user requests, then, would reach the reverse proxy, that would serve them from cache if possible, or forward them to the internal web servers, and send the response back to the user, transparently. Notice that this is an internal operation, not a redirect response.
Although this setup is more complex than the simpler solution of using different subdomains (www.mysite.com for website and portal.mysite.com for application), it comes with certain advantages that are described in the referenced Wikipedia article, such as security and acceleration.
Alternatively you could create separate subdomains as described above, and use a redirect rule to redirect requests for www.mysite.com/portal/x to portal.mysite.com/x. In this case, the user would see the updated URL in their browser, but the old ones would still work.
I have a site that lets people have their own e-stores, for ex- mysite.com/clientname
What I want is, if somebody opens store.clientname.com or clientname.com/store, the content is pulled from mysite.com/clientname. [ So that their users feel that they are browsing on their site ]
I know this is possible because site'e like tumblr let you do that by changing a CNAME entry for your domain to their IP address.
I do have a dedicated IP address.
Also, can this be done by editing the .htaccess file at clientname.com, and if yes, which method is better/easy?
You'll want to solve the problem in a completely different way for http://store.clientname.com/ versus http://clientname.com/store.
In the first case, you can serve the web site as a virtual host. Just set up a virtual host called store.clientname.com and set its DocumentRoot to be the existing directory that contains the files for http://mysite.com/clientname. If you have other web server configuration directives that apply to http://mysite.com/clientname then you'll also want to apply those in the virtual host. Finally, the client can set up a CNAME record in DNS for store.clientname.com pointing to your web server.
If you are using Apache, you can also use a default virtual host and mod_rewrite to dynamically translate URLs of the form http://store.{whatever}/ to http://mysite.com/{whatever}/. However, this won't work if you are using HTTPS.
In the second case, you don't want to serve the web site at http://clientname.com/ because the client presumably is already hosting that and presumably http://clientname.com/otherstuff has to continue working and come from their server. So the second case is easier for you because all the work has to be done on the client's web server. But it's simple: they will just have to configure their web server to proxy http://clientname.com/store to http://mysite.com/clientname.