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.
From the nginx documentation,
return
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 theauth_request
and since the path_
does not exist, it falls through when theauth_request
passes, but returns 401 or 403 if it does not: