Let's say I have two web apps on Heroku. For example foobar-signup.heroku.com, and foobar-conferences.heroku.com.
If I wanted to map routes from under www.foobar.com/signup and www.foobar.com/conferences to the same routes on those two backend apps (i.e. www.foobar-signup.heroku.com/signup, ...), what services, applications, and configurations should I use to do that.
You have to use proxy pass to do that.
For that, you can use apache (as it is very easy to use). Now in your proxy file, you have to map all requests from
www.foobar.com/signup to www.foobar-signup.heroku.com/signup
and
www.foobar.com/conferences to www.foobar-conferences.heroku.com/conferences
Now when you open www.foobar.com/signup page, proxy pass will redirect it to www.foobar-signup.heroku.com/signup page. Thereby solving your problem.
Edit your httd.conf file,
ProxyPass /signup/ http://www.foobar-signup.heroku.com/signup/
ProxyPass /conferences/ http://www.foobar-conferences.heroku.com/conferences/
Related
I came into a situation today. Please share your expertise 🙏
I have a project (my-app.com) and one of the features is to generate a status page consisting of different endpoints.
Current Workflow
User login into the system
User creates a status page for one of his sites (e.g.google) and adds different endpoints and components to be included on that page.
System generates a link for a given status page.
For Example. my-app.com/status-page/google
But the user may want to see this page in his custom domain.
For Example. status.google.com
Since this is a custom domain, we need on-demand TLS functionality. For this feature, I used Caddy and is working fine. Caddy is running on our subdomain status.myserver.com and user's custom domain status.google.com has a CNAME to our subdomain status.myserver.com
Besides on-demand TLS, I am also required to do reverse proxy as
shown below.
For Example. status.google.com ->(CNAME)-> status.myserver.com ->(REVERSE_PROXY)-> my-app.com/status-page/google
But Caddy supports only protocol, host, and port format for reverse proxy like my-app.com but my requirement is to support reverse proxy for custom page my-app.com/status-page/google. How can I achieve this? Is there a better alternative to Caddy or a workaround with Caddy?
You're right, since you can't use a path in a reverse-proxy upstream URL, you'd have to do rewrite the request to include the path first, before initiating the reverse-proxy.
Additionally, upstream addresses cannot contain paths or query strings, as that would imply simultaneous rewriting the request while proxying, which behavior is not defined or supported. You may use the rewrite directive should you need this.
So you should be able to use an internal caddy rewrite to add the /status-page/google path to every request. Then you can simply use my-app.com as your Caddy reverse-proxy upstream. This could look like this:
https:// {
rewrite * /status-page/google{path}?{query}
reverse_proxy http://my-app.com
}
You can find out more about all possible Caddy reverse_proxy upstream addresses you can use here: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#upstream-addresses
However, since you probably can't hard-code the name of the status page (/status-page/google) in your Caddyfile, you could set up a script (e.g. at /status-page) which takes a look at the requested URL, looks up the domain (e.g. status.google.com) in your database, and automatically outputs the correct status-page.
I understand what SPA routing is, but there is one aspect I never fully understood, and I don't know if the answer to the question is library specific, server-site specific, or both.
When running a SPA development server locally, the routing is obvious. For instance the frontend route /user/login is served by the development server under https://<SERVER-IP>/user/login.
However, how does that work in production? For example, in production there is an NGINX instance running that statically serves the SPA build files from http://some-domain/some/path, in particular the main http://some-domain/some/path/index.html. On server site, this typically requires a certain configuration that ensures that requests on sub-paths get redirected to the index.html, as explained e.g. by this answer in case of NGINX.
What isn't clear to me: How can the app extract the frontend route from the URL after redirection? For instance: If the request is http://some-domain/some/path/user/login how does the app router knows the relevant part of the URL is /user/login? I see two possible explanation:
Either it is possible to maintain the "base URL" information in the redirect, or
Does this in general require a special (production specific) configuration of the frontend router library?
I have a website with a separate subdomain for static files. I found out that I need to set the Access-Control-Allow-Origin header in order for certain AJAX features to work, specifically fonts. I want to be able to access the static subdomain from localhost for testing as well as from the www subdomain. The simple solution seeems to be Access-Control-Allow-Origin: *. My server uses nginx.
What are the main reasons that you might not want to use a wildcard for Access-Control-Allow-Origin in your response header?
You might not want to use a wildcard when e.g.:
Your web and let’s say its AJAX backend API are running on different domains, or just on different ports and you do not want to expose backend API to whole Internet, then you do not send *. For example your web is on http://www.example.com and backend API on http://api.example.com, then the API would respond with Access-Control-Allow-Origin: http://www.example.com.
If the API wants to request cookies from client it must not send Access-Control-Allow-Origin: *, but its value must be the value of the origin from the actual request.
For testing, actually adding entry in /ets/hosts file for 127.0.0.1/server-public-ip dev.mydomain.com is a decent workaround.
Other way can be to have another domain served by nginx itself like dev.mydomain.com pointing to the same/test-instance of backend servers & static-web-root with some security measures like:
satisfy all;
allow <YOUR-CIDR/IP>;
deny all;
Clarification on: Access-Control-Allow-Origin: *
This setting protects the users of your website from being scammed/hijacked while visiting other evil-websites in a modern-browser which respects this policy (all known browsers should do).
This setting does not protect the webservice from scraper scripts to access your static-assets & APIs at rapid speed - doing bruteforce attacks/bulk downloading/causing load etc.
P.S: (1) For development: you can consider using a free, low-footprint private-p2p vpn-like network b/w your development box & server: https://tailscale.com/
In my opinion, is that you could have other websites consuming your API without your explicit permission.
Imagine you have an e-commerce, another website could do all the transactions using their own look and feel but backed by you, for you, in the end, it is good because you will get the money in the end but your brand will lose its "recognition".
Another problem could be if this website would change the sent payload to your backend doing things like changing the delivery address and other things.
The idea behind is just to not authorize unknown websites to consume your API and show its result to users.
You could use the hosts file to map 127.0.0.1 to your domain name, "dev.mydomain.com", as you do not like to use Access-Control-Allow-Origin: *.
I have a few apps running in a aws instance with Dokku. I'm using virtual hostname, and together with some DNS configuration of my registered domain, I have the following for one of them: mydomain.com is a CNAME record pointing to the aws instance address, and Dokku+nginx take care of redirecting to the correct app/process.
The path for all API calls is /parse, as I'm using the open source Parse Server. The final server url is mydomain.com/parse.
What I want to achieve, ideally, is the following: api.mydomain.com gets redirected to mydomain.com/parse, api.mydomain.com/someFunction to mydomain.com/parse/someFunction and so on.
When researching to see how this may be possible, I found that this can be done easily with nginx, like explained here in this answer.
I can even change manually the nginx config file, but I'm afraid that it will be overwritten in future changes. How can this ideally be achieved with nginx on Dokku?
I am running behind a CDN that turns my https request into http and sets X-Forwarded-Proto.
I know in nginx I can create a rule that rewrites my request as
localhost:8080/VirtualRequestBase/https/realsite.com:80/VirtualHostRoot/siteroot so that urls come out right.
However I have a zope setup where I keep many sites and I don't want to have to change the nginx config every time I add a new one. I normally use the VHM mappings tab to map domains to siteroots, however it will ignore the VirtualHostBase directive in the path. In addition you can mix the two styles of VHM, ie set localhost:8080/VirtualRequestBase/https/realsite.com:80/ and expect it use the mappings.
Any ideas?