Um cenário banal. Tivemos o seguinte local declarado para testar se o servidor está acessível:
location = /ping {
return 204;
}
Decidimos que queremos protegê-lo com a mesma lógica auth_request que temos para outros endpoints, que funcionam e estão contidos no mesmo server {}
bloco. Nós simplesmente adicionamos a auth_request
diretiva, mas ambas as tentativas falharam:
Este sempre retorna 204, mesmo quando o auth_request retorna 401/403:
location = /ping {
auth_request /validate;
return 204;
}
o que é uma surpresa, dado o comportamento documentado para auth_request , presumi que simplesmente pararia de processar outras diretivas:
Se a subsolicitação retornar um código de resposta 2xx, o acesso é permitido. Se retornar 401 ou 403, o acesso é negado com o código de erro correspondente.
Uma segunda tentativa de retornar diretamente o status do auth_request também não funcionou:
location = /ping {
auth_request /validate;
auth_request_set $auth_status $upstream_status;
return $auth_status;
}
como falha com
[emerg] código de retorno inválido "$auth_status" em /etc/nginx/conf.d/default.conf:157
O problema parece relacionado ao meu uso de return
? Eu vi nginx auth_request como retornar o código de status de back-end, mas não parece resolver minha situação.
Da documentação do nginx ,
return
É importante ressaltar que o "stops processing" não ocorre no ponto em que a diretiva é encontrada, portanto, o retorno sempre acontece independentemente do resultado da subsolicitação.
O objetivo era simplesmente proteger meu
/ping
endpoint e essa pequena modificação funciona:try_files
é claro que está sujeito aoauth_request
e como o caminho_
não existe, ele cai quando oauth_request
passa, mas retorna 401 ou 403 se não: