My AngularJS application running on NGINX server user profiles. I want users to point their domains to their profiles.
Example http://example1.com would serve http://example.com/#/foo profile.
I have created a custom nameserver i.e. ns1.example.com but I am not sure how to configure NGINX to point to the correct user account.
This is the sort of thing that you'll want to handle at the application level, and not in Nginx. That is, rather than updating and reloading your Nginx config files you should have something server side (like a lightweight Node.js application, for example) that would inspect the Host header. If the Host header value isn't your domain, then look up that domain in your database and serve up a 301 redirect..
Also note that there are some compatibility problems with using a redirect to an anchor fragment (like #/foo). Make sure you test well with the browsers that your users use most commonly.
Related
I am building a multi tenant app using MERN stack. While learning about best practices to identify tenant, i fixed on subdomain approach. For example, on browsing URL like
tenant1.mydomain.com,
tenant2.mydomain.com
etc., the tenant1/tenant2 part of the URL is extracted as tenant identity to further authenticate users and start the app. As mentioned on https://github.com/facebook/create-react-app/issues/2292#issuecomment-302894212, i set up .env so CRA (npm run start) development server can serve on mapped domain instead of default localhost:3000 on development machine.
I suppose the approach works only for single tenant due to single subdomain mapping in .env, but don't know if and how multiple tenants can be taken care of. This whole stuff is new to me and i appreciate all possible help i can get to achieve multi tenancy goal.
There are a few ways to do this, I particularly create a redirection of the subdomains to my main application domain. And this works for both development and production.
Initially I left it in fixed development like you did, but now I do it
as if it were in production, it makes the development more dynamic and
real.
On any system you have the HOST file.
Their path is usually in:
Windows 10: “C:\Windows\System32\drivers\etc\hosts”
Linux: “/etc/hosts”
Mac OS X: “/private/etc/hosts”
In the HOST file I point the subdomains to my local ip or application ip. Something like:
127.0.0.1 client1.myapp.com
127.0.0.1 client2.myapp.com
127.0.0.1 client3.myapp.com
In this case it's local but it works for production, so when I run my app I don't need to use 127.0.0.1 or localhost, I can use one of those domains, and even if they point to the same IP, that way I can get the domain from the client inside application, such as:
const domainName = window.location.hostname;
And now just use the domain to make the multitenancy logic work.
I have the following two domains:
myVeryLongSiteDomain.com
mVeryShortURL.co
I need the following short URLs:
mVeryShortURL.com/123456789
mVeryShortURL.com/a-DSa131_
To redirect to the long site domain like so:
myVeryLongSiteDomain.com/feedback/123456789
myVeryLongSiteDomain.com/feedback/a-DSa131_
Note, how the /feedback/ url path is added
How can I make this work? Is it possible with just DNS? Do I need to host a app just for the ShortURL domain that does this redirection? FYI, my longsitedomain is a react app hosted on heroku.
What is the cleanest, right way, to make this happen?
Sadly, no, the redirection is not possible using only DNS. DNS can only gives you an IP-Address which your browser will contact.
You will need to host an app (extra server, virtual host, heroku app, ...) which does the redirection. Since it doesn't do much, this can be really lightweight. Since you are using 2 different apps, the framework you are using for your main app doesn't matter at all.
One way of doing it is to use a small php wrapper script which does the redirection and using mod_rewrite to make your apache to route all requests to your main php file. The mod_rewrite part is explained here
Another way comes without any scripting and only a webserver:
Apache: Redirect all request from old domain to new domain
Nginx: Nginx redirect all old domain subdomains to new one
If your main site uses HTTPS, which is very likely, since you are using Heroku, your redirection site should do the same. Should domains which only make redirects (aka tiny urls) be encrypted (https)?
Maybe this is a really basic question, but how do you architect your system such that your single page application is hosted on premise with some hostname, say mydogs.com but you want to host your application services code in the cloud (as well as database). For example, let's say you spin up an Amazon EC2 Container Service using docker and it is running NodeJS server. The hostnames will all have ec2_some_id.amazon.com. What system sits in from of the Amazon EC2 instance where my angularjs app connects to? What architecture facilitate this type of app? Especially AWS based services.
One of the important aspects setting up the web application and the backend is to server it using a single domain avoiding cross origin requests (CORS). To do this, you can use AWS CloudFront as a proxy, where the routing happens based on URL paths.
For example, you can point the root domain to index.html while /api/* requests to the backend endpoint running in EC2. Sample diagram of the architecture is shown below.
Also its important for your angular application to have full url paths. One of the challenges having these are, for routes such as /home /about and etc., it will reload a page from the backend for that particular path. Since its a single page application you won't be having server pages for /home and /about & etc. This is where you can setup error pages in CloudFront so that, all the not found routes also can be forwarded to the index.html (Which serves the AngularJS app).
The only thing you need to care about is the CORS on whatever server you use to host your backend in AWS.
More Doc on CORS:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Hope it helps.
A good approach is to have two separated instances. It is, an instance to serve your API (Application Program Interface) and another one to serve your SPA (Single Page Application).
For the API server you may want more robust service because it's the one that will suffer the most receiving tons of requests from all client instances, so this one needs to have more performance, band, etc. In addition, you probably want your API server to be scalable when needed (depends on the load over it); maybe not, but is something to keep in mind if your application is supposed to grow fast. So you may invest a little bit more on this one.
The SPA server in the other hand, is the one that will only serve static resources (if you're not using server side rendering), so this one is supposed to be cheaper (if not free). Furthermore, all it does is to serve the application resources once and the application actually runs on client and most files will end up being cached by the browser. So you don't need to invest much on this one.
Anyhow, you question about which service will fit better for this type of application can't be answered because it doesn't define much about that you may find the one that sits for the requisites you want in terms of how your application will be consumed by the clients like: how many requests, downloads, or storage your app needs.
Amazon EC2 instance types
I have a portal that, for legacy reasons, have multiple domains.
On the portal settings, i set to redirect all alias to the primary alias.
Works fine for http, but if the url to the non primary domains has specified https protocol the user gets a 404 error.
Portal is running on dnn version 8.0.3.
To my knowledge, the core in no way supports SSL. There are two 3rd party solutions for SSL you can buy that I know about:
SSL Module 3.2 from Thomas Thorpe (http://www.snowcovered.com/snowcovered2/Default.aspx?tabid=166&CatalogItemID=1505&CatalogID=7&search=SSL&pagenumber=0&sortby=&tagid=-1)
SSL Redirect 1.0 from Sanibel Logic LLC (http://www.snowcovered.com/snowcovered2/Default.aspx?tabid=166&CatalogItemID=3155&CatalogID=7&search=SSL&pagenumber=0&sortby=&tagid=-1)
I currently use the first one and it does the job. I am using version 3.1 of it, and I have experienced some issues with it around the setting of the redirects it lets you configure. But, if you don't touch that, and just use a basic configuration, it works. Also be cautious that it says it supports a shared SSL certificate environment (like a common SSL cert you get in a basic shared hosting account), which it does, but it will only support this for a single portal because it forces you to add that shared SSL domain in as a portal alias. Because portal aliases are unique, you can only set it up for a single portal, not all portals on your host. It looks like he is up to version 3.2 now, so these things may have changed.
I have not used the second module. It looks like it takes a little different approach from the first and allows you to setup general SSL rules for all portals on a host, instead of configuring each portal specifically.
Both I believe require you to make a change to your web.config to add an additional httpModule. They do this to intercept web requests to pages, and if it decides it is a page you have said you want to be secure, it then redirects to the same page with the https prefix and vice versa before any content is sent to the user . I don't think this is the ideal solution because of the multiple server hits involved, but it works.
Credit: dnnsoftware/com/forums/threadid/21470/scope/posts/how-to-set-https-instead-of-http-for-portal-alias
For our e-commerce service running on AppEngine we would like to offer the option for customers to run the stores on their custom domains (eg: www.mystore.com instead of www.enstore.com/mystore).
From a user perspective, I'd like them to enter the domain name they want to use in their preference screen and tell them how to configure their dns.
I know how you normally add domains to an AppEngine instance (through Google Apps) but I'm not sure you can automate that. And even if that's possible they would be all (hundreds) listed on our google apps page.
Anyone know if this is possible/if there is a good way to do it?
I don't think there is a way to add domains "programatically" to an AppEngine instance. Apparently, domains can only be added by using the Google Apps method that you described. This is confirmed in this SO post: How do i get foo.somedomain.com get handled by myapp.appspot.com/foo on appengine
The only options that pop to mind are the following:
HTTP Redirection
Many DNS providers support HTTP Redirection. In this case, your clients would be able to set up mystore.com and www.mystore.com to redirect to www.enstore.com/mystore. There are some obvious disadvantages with this method that might not be acceptable. First of all, with 301 and 302 redirects, the users will still be forwarded to the registered AppEngine URL: www.enstore.com/mystore, and it will show in their browser. In addition, choosing between a 301 and 302 redirect can make SEO tricky, since you'd have to get into how search engines behave with these redirects. For example most search engines will not use the original URL as a source for keywords when you use a 301 redirect.
In addition to 301 and 302 redirects, some DNS providers (like DNS Made Easy) also provide what they call a "masked hidden-iframe redirect". The page will render inside a hidden iframe, so the URL does not change in the user's browsers. However this makes SEO even more tricky, and it will not allow users to bookmark internal pages, or to reference them easily.
As you can see, this option is less than ideal, but it is one option to consider in some situations. Also note that at the moment, HTTP Redirection using 301 redirects is the suggested workaround for the Naked Domain Issue 777 on the AppEngine issue tracker.
Reverse Proxy
Another option could be to set up a small server somewhere else, like a small Amazon EC2 Instance, and set up a simple reverse proxy. You would be able to set this up very easily, just by using Apache and mod_proxy (or various other alternatives). This would allow you to ask your clients to set up a normal A Record pointing to this instance, while the Apache HTTP server would be acting as a proxy to your AppEngine.
The fundamental configuration directive to set up a reverse proxy in mod_proxy is the ProxyPass. You would typically set it up with one line like these for each VirtualHost (for each client domain):
ProxyPass / http://www.enmystore.com/mystore/
The configuration of the remote proxy could be easily handled by your back-end software.
This is a neater solution which gives you plenty of control - but there are obviously some costs for these benefits. First of all, there is the expense to host the reverse proxy. You would also be adding another point of failure, so you have to add this to your high-availability plan. In addition, if you are serving some pages through SSL it can become quite complicated.
Another option is to have each customer sign up for google apps, and then add your appengine app to their app. That way they can manage the url. They will need to use a cname for this, so urls will be limited to something like 'store.customer.com' You will have to support the multitenancy off of the host-header, but that isn't hard to do given that you already have a way to support multitenancy already. You might want to do the setup for the first couple of clients yourself so you can document the easiest way to set it up.
The rietveld code review app does this as you can add it to your google apps domain. See http://code.google.com/p/rietveld/wiki/CodeReviewHelp#Using_Code_Reviews_with_Google_Apps for more detail.
The preferred option is probably to offer your solution through the Google Solutions Marketplace: http://www.google.com/enterprise/enterprise_marketplace/about.html
We did something similar to Daniel Vassallo second proposal.
We created a python app on the Heroku cloud
(there is no limit for connecting custom domains).
This app is using python requests 1.2.0 lib to get the correct page from your app engine application according to the request domain.
all you need to tell your clients is to put your Heroku app url as their CNAME
For naked domains you can always use wwwizer