3

I am using Nginx to proxy pass to my wsgi app served with Circus.

I want to allow the traffic to that app for some urls of the app only for some IP address.

For now it look like this:

server {
    listen   80;
    server_name  service.dev;
    access_log  /var/log/service.access.log;
    error_log  /var/log/service.error.log debug;

    location / {
        try_files $uri @proxy_to_app;
    }

    location @proxy_to_app {
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_pass         http://127.0.0.1:9000/;
    }

    location /admin/ {
        allow 192.168.5.0/24;
        deny all;
    }
}

But it doesn't work. If I have the right, I get a 404 error instead of the proxy_pass.

Do you know how I can do that without having to copy/paste the proxy_pass configuration each time?

Thank you.

Natim
  • 616
  • 1
  • 6
  • 16

1 Answers1

3

EDIT 2

As per VBart's comments, I've changed the entries in try_files to $uri @proxy_to_app. This avoids any confusion over the order of named locations (they must always come last). Be advised that if the /admin/ directory exists locally, this will be used instead of the proxy.

EDIT

If you really want to use a named location to avoid duplicating proxy_pass for each location, you can use the following:

server {
    listen       80;
    server_name  service.dev;
    access_log   /var/log/service.access.log;
    error_log    /var/log/service.error.log debug;

    location / { 
        # Catch all 
        try_files $uri @proxy_to_app;
    }   

    location /admin/ {
        # /admin/ only
        allow 192.168.5.0/24;
        deny  all;
        try_files $uri @proxy_to_app;
    }   

    location @proxy_to_app {
        proxy_set_header  Host $http_host;
        proxy_redirect    off;
        proxy_pass        http://127.0.0.1:9000;
    }   
}

It's a bit of a hack, try_files requires at least two parameters, in the first instance it will look for a local path with the same $uri (if you want to override with local files). In the second instance I've specified /dev/null as the second path; this will never be used.

ORIGINAL

Try this configuration:

server {
    listen       80;
    server_name  service.dev;
    access_log   /var/log/service.access.log;
    error_log    /var/log/service.error.log debug;

    # Proxy settings
    proxy_set_header   Host $http_host;
    proxy_redirect     off;

    location / {
        # Catch all
        proxy_pass     http://127.0.0.1:9000/;
    }

    location /admin/ {
        # /admin/ only
        allow 192.168.5.0/24;
        deny  all;
        proxy_pass     http://127.0.0.1:9000/;
    }
}

The location / block should only catch URIs that are not matched subsequently in other location blocks.

plasmid87
  • 1,888
  • 15
  • 17
  • Thank you it is what I did with the `try_files`. – Natim Nov 14 '13 at 11:00
  • `try_files @proxy_to_app /dev/null;` - this doesn't work. See [the docs](http://nginx.org/r/try_files), it checks **files on disk**. – VBart Nov 14 '13 at 11:46
  • I've tried the configuration out locally (nginx 1.0.15) and it works. What error are you getting? I think you're confused, `try_files` does more than check files on disk... – plasmid87 Nov 14 '13 at 11:48
  • No, it only checks files on disk, and if they all are missing, then internal redirect is performed (in your case it redirects to `/dev/null`, that is caught by `location /` and passed to `http://127.0.0.1:9000/`) – VBart Nov 14 '13 at 11:54
  • That's the intended behaviour, after allow/deny is processed. I have made it clear that this is a *hack*. Can you suggest a better alternative? – plasmid87 Nov 14 '13 at 11:59
  • What you have seen is the result of processing `http://127.0.0.1:9000/dev/null`. This definitely is not what author expects for `/admin/blabla` requests. – VBart Nov 14 '13 at 12:02
  • I recommend to duplicate `proxy_pass` configuration (like in your ORIGINAL example). It's the nginx way of configuration, dumb and simple. – VBart Nov 14 '13 at 12:03
  • OK, I've just setup another clean test environment - can doubly confirm my configuration works and that pages served under `/admin` are 403 forbidden if not in the correct IP range. When the IP is correct, you can access files under `/admin`. Please, I urge you to test this configuration yourself - it works exactly as described. – plasmid87 Nov 14 '13 at 12:10
  • Please note, that `/admin` isn't the same as `/admin/`. – VBart Nov 14 '13 at 12:16
  • Are your configuration look exactly like in your `EDIT` listing, or you have simplified it somehow? – VBart Nov 14 '13 at 12:20
  • "at least" was missing from my answer. The configuration works, withstanding it exploits a nuance in Nginx's request handling. If you have a better mechanism for keeping `proxy_pass` in a named location, please post it - it's an interesting problem. I'm in The Comms Room chat if you want to discuss this further. – plasmid87 Nov 14 '13 at 12:24
  • Sorry, but it can't work. It passes `GET /dev/null HTTP/1.0` to backend, while the original request was `GET /admin/some HTTP/1.0`. You have been so stubborn that I even tested it myself. – VBart Nov 14 '13 at 12:36
  • Ok, after `EDIT 2` it looks right. – VBart Nov 14 '13 at 12:44
  • Thanks for the feedback @VBart. Indulge me - I've posted the exact configuration I was using [here](http://pastebin.com/XR7UuEvn). All three options (including the commented out sections) work. I've been tailing the logs, all the requests are correct, can't see any requests for "/dev/null". I'm running Nginx 1.0.15 on CentOS (EPEL). – plasmid87 Nov 14 '13 at 12:56
  • 1
    Well, now I see. It's a bug in nginx 1.0.15, that was fixed in 1.1.12. A quote from [changelog](http://nginx.org/en/CHANGES): _Bugfix: a "proxy_pass" directive without URI part might use original request after redirection with the "try_files" directive._ We have fixed it about two years ago, so I even don't remember. – VBart Nov 14 '13 at 13:16
  • +1 excellent spot! You can see why I was stubborn - it *does* work here :) 1.0.15 is the newest version of Nginx EPEL offers at the moment, hopefully an update will be coming soon. – plasmid87 Nov 14 '13 at 13:21
  • 1
    I would recommend you to use our packages: http://nginx.org/en/linux_packages.html (always fresh and secure). – VBart Nov 14 '13 at 13:26