1

A trivial scenario. We had the following location declared to test if the server is reachable:

location = /ping {
    return 204;
}

We have decided that we want to protect it with the same auth_request logic we have for other endpoints, which work and are contained within the same server {} block. We simply added the auth_request directive but both attempts have failed:

This one always returns 204, even when the auth_request returns 401/403:

location = /ping {
    auth_request /validate;
    return 204;
}

which is somewhat of a surprise, given the documented behaviour for auth_request, I assumed it would simply stop processing further directives:

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.

A second attempt to directly return the auth_request's status directly also didn't work:

location = /ping {​​​​​​​​
    auth_request /validate;
    auth_request_set    $auth_status        $upstream_status;
    return $auth_status;
}​​​​​​​​

as it fails with

[emerg] invalid return code "$auth_status" in /etc/nginx/conf.d/default.conf:157

The problem seems related to my use of return? I have seen nginx auth_request how to return backend status code but it doesn't appear to address my situation.

msanford
  • 1,427
  • 15
  • 27

1 Answers1

1

From the nginx documentation, return

Stops processing and returns the specified code to a client.

Importantly, the "stops processing" does not occur at the point the directive is encountered, so the return always happens regardless of the subrequest's result.

The goal was simply to protect my /ping endpoint and this tiny modification works: try_files is of course subject to the auth_request and since the path _ does not exist, it falls through when the auth_request passes, but returns 401 or 403 if it does not:

location = /ping {
    auth_request /validate;
    try_files _ =204;
}
msanford
  • 1,427
  • 15
  • 27