Nginx auth_request how to return backend status code

authorizationnginx

when the backend proxy used in auth_request returns an error code different from 401 or 403, nginx is returning a 500 error code.

The ngx_http_auth_request_module module (1.5.4+) implements client authorization based on the result of a subrequest. If the subrequest returns a 2xx response code, the access is allowed. If it returns 401 or 403, the access is denied with the corresponding error code. Any other response code returned by the subrequest is considered an error.

Is there a way to make nginx returns the status code from the backend and not 500 ?

Best Answer

I found a working solution. It uses the fact that auth_request will always return a 500 error code in case of a backend error different from 401 or 403 :

error_page 500 @process_backend_error;

location / {
    auth_request /auth
    auth_request_set $backend_status $upstream_status
}

location /auth {
    proxy_pass ...
}

location @process_backend_error {
    # here you have access to $backend_status which contains the returned status code from your autorization backend
}

Beware that the returned status code in $backend_status is a string.

Related Solutions

NGINX return correct headers with custom error documents

Drop the = out of the error_page directive; you can specify any return code you like with =NNN (eg =401), but if you give a bare = it means "use the error code of the error handler", which for a static file will always be "200 OK". Without any =, you'll get the original error code returned.

Irritatingly, a straightforward reading of the (otherwise) fine manual (as at the time of writing this answer, anyway) might make you think that it's the other way around (= keeps the original return code), but local testing indicates that it definitely works the way I've described above.

Nginx – How to return 403 instead 500 response code after auth_request fails

This might help:

If you want to display your own page instead of the default error page provided by DotCloud, you have to use a few tricks.

First, note that this will only work for stacks that embed a Nginx server. For other stacks, DotCloud load balancers will be the only layer between your user and your app, and for now, it can only serve a default error page.

You need to tell Nginx to do all those things:

use a custom static page for 502 and 504 errors; remap the error code to e.g. 500 (else, the DotCloud load balancers will serve the default 502 and 504 pages); intercept the errors sent by the uwsgi/fastcgi (else, our custom static page won’t be used); reduce the default timeout, so your timeout handler will kick in before the platform-wide timeout handler. Assuming your error pages are in /static/502.html and /static/504.html, you can use the following nginx.conf snippets:

PHP:

fastcgi_read_timeout 10;
fastcgi_intercept_errors on;
error_page 502 =500 /static/502.html;
error_page 504 =500 /static/504.html;

Perl/Phython:

uwsgi_read_timeout 10;
uwsgi_intercept_errors on;
error_page 502 =500 /static/502.html;
error_page 504 =500 /static/504.html;

Ruby:

For Ruby applications, since Passenger will use error code 500, no rewriting is needed. The default Nginx configuration already provides a handler for that (errorpage 500 /static/500.html). Also, since Passenger does not expose a configuration variable to change the timeout, you cannot provide a custom 504 page.

Once you enable intercept_errors in Nginx, you can no longer generate your own error pages for e.g. HTTP codes 500, 403, etc. You have to define static pages for those errors in Nginx as well. This limitation will be lifted in a future version of the services.

Source: http://docs.dotcloud.com/guides/5xx/

Otherwise, Check out this page on http://wiki.nginx.org/NginxVariableTutorialCn06 that provides a decent tutorial on it. [Although I recommend translating the page via google chrome...]

Best Answer

Related Solutions

NGINX return correct headers with custom error documents

Nginx – How to return 403 instead 500 response code after auth_request fails

Related Topic