0

I finished developed an app that features a downloading system that is hosted with NGINX at:

http://dashboard.myapp.com

The URL for downloads is:

http://dashboard.myapp.com/download/file-slug

This page is a regular PHP page that will require some user input and then PHP handles the actual file download, it's not the direct path for the file.

Since these download URLs will be made publicly available, I want to ditch that dashboard subdomain.

The default domain (myapp.com) is already working with a wordpress setup with this:

    location / {
            try_files $uri $uri/ /index.php?q=$uri&$args;
    }

Is there an easy way to get the:

http://myapp.com/download/file-slug

to act as if:

http://dashboard.myapp.com/download/file-slug

was accessed, without actually redirecting?

Rui Gomes
  • 332
  • 1
  • 3
  • 16
  • "To act as if..." - Please explain what you mean. Do you want to continue to use the subdomain, but the user sees `myapp.com/download/file-slug`, such as if it's on a different server? – Mat Carlson Mar 19 '14 at 22:43
  • Yes, the user would then be able to access with or without the dashboard subdomain. – Rui Gomes Mar 19 '14 at 22:44
  • Are the files on the same server, and you just want the URL the user sees to not have `dashboard.myapp.com`? – Mat Carlson Mar 19 '14 at 22:46
  • Yes, the desired behaviour is not to see the dashboard.myapp.com. – Rui Gomes Mar 19 '14 at 22:50
  • However /download/file-slug is just a regular PHP page, no actual files involved, it does not trigger any download. – Rui Gomes Mar 19 '14 at 22:51
  • What happens if you copy the PHP file to `myapp.com/download/file-slug`? – Mat Carlson Mar 19 '14 at 22:52
  • I'm using a rather large PHP framework, so that is not an option, everything is included and routed accordingly from an index.php. – Rui Gomes Mar 19 '14 at 22:55

2 Answers2

1

Try this - Place in your server block for myapp.com, anywhere outside another location block. Set the root to the same root as the dashboard subdomain (if on the same server). The script would see itself as being hosed at myapp.com instead of dashboard.myapp.com, but it should retain the remainder of the framework rules. If this doesn't work, try the next option.

location /download/file-slug { 
    root /path/folder;  
    try_files  $uri $uri/ /index.php?q=$uri&$args;
}

Another option is to proxy through Nginx. This option actually runs the script on the current location, accessing it like a client would through dashboard.myapp.com. See proxy_pass documentation on Nginx.org. 

location /download/file-slug { proxy_pass http://dashboard.myapp.com/download/file-slug; }
Mat Carlson
  • 543
  • 3
  • 12
  • I forgot to mention that the route /download/file-slug is actually for a regular PHP page that will require for some input and then the PHP handles downloading the file, so that solution wouldn't work. – Rui Gomes Mar 19 '14 at 22:36
  • I've changed the initial option a bit - Essentially it would run your code from the other subdomain as if it were on `myapp.com`. If that won't work, try the second one which just proxies to `dashboard.myapp.com`. The top one is probably a better option if it works, but really it doesn't matter too much. – Mat Carlson Mar 19 '14 at 23:03
  • I think I should explain my methodology a little bit - Using `proxy_pass` should be avoided if possible. When you use `proxy_pass` in this way, it has to run a DNS query, handle the TCP overhead, and deal with the response time of the other server. It's not a bad thing, but can increase response time. Security - Somewhat null since you declare Google's DNS, but someone could hijack your requests if they know what they are doing (very unlikely). Reliability - If the other server/instance goes down, you appear to lose your main site too. – Mat Carlson Mar 19 '14 at 23:54
0

I was able to work it out with Nginx only.

Inside the myapp.com config file I added:

    location ~ /download/(.*) {
            resolver 8.8.8.8; 
            proxy_pass http://dashboard.myapp.com/download/$1;
    }

The resolver 8.8.8.8 is actually using Google DNS. Without this line I was getting a "no resolver defined to resolve" error.

Rui Gomes
  • 332
  • 1
  • 3
  • 16
  • Do **NOT** use a publicly accessible DNS server such as `8.8.8.8`. [To prevent DNS spoofing, it is recommended configuring DNS servers in a properly secured trusted local network.](http://nginx.org/en/docs/http/ngx_http_core_module.html#resolver) – Tim Oct 07 '16 at 20:14