Como retornar o código de resposta 403 em vez de 500 depois que auth_request falhar

Question

É possível retornar um código de resposta 403 após o módulo nginx auth_request retornar com 403, para que uma diretiva proibida também seja mostrada ao usuário, em vez de um erro interno de 500 servidores, o que não é muito informativo.

    

Answer 1

Obrigado ao Zero Stack por sua ajuda, mas acabei de encontrar a resposta por minha conta, parece que cometi um erro de configuração em primeiro lugar. Eu configuro o nginx como um proxy ssl transparente para servir conteúdo http por meio de uma conexão ssl. Para autenticação, usei o módulo auth_request, que não está incluído nos pacotes padrão do nginx.

Portanto, agora, sempre que recusei um pedido do meu servidor de autenticação, o nginx serviu uma página 500er, o que o torna ímpar, uma vez que o módulo deveria ter definido um código de erro 403. Mas eu não consegui descobrir por que o nginx interpretou isso como um erro 500. Por acaso eu descobri que eu deveria ter configurado o proxy_pass para NÃO interceptar as páginas de erro!

A solução para meu problema específico é definir:

proxy_intercept_errors off;

Hmm alguma opinião, o que fazer com a recompensa?

    

Answer 2

Isso pode ajudar:

Se você deseja exibir sua própria página em vez da página de erro padrão fornecida pelo DotCloud, você tem que usar alguns truques.

Primeiro, observe que isso só funcionará para pilhas que incorporam um servidor Nginx. Para outras pilhas, os balanceadores de carga do DotCloud serão a única camada entre o usuário e seu aplicativo e, por enquanto, só poderão exibir uma página de erro padrão.

Você precisa dizer ao Nginx para fazer todas essas coisas:

use uma página estática personalizada para erros 502 e 504; remapear o código de erro para, e. 500 (senão, os balanceadores de carga DotCloud servirão as páginas padrão 502 e 504); interceptar os erros enviados pelo uwsgi / fastcgi (caso contrário, nossa página estática personalizada não será usada); reduza o tempo limite padrão, para que seu manipulador de tempo limite seja ativado antes do manipulador de tempo limite da plataforma. Supondo que suas páginas de erro estejam em /static/502.html e /static/504.html, você pode usar os seguintes snippets nginx.conf:

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:

Para aplicativos Ruby, como o Passenger usará o código de erro 500, não é necessário reescrever. A configuração padrão do Nginx já fornece um manipulador para isso (errorpage 500 /static/500.html). Além disso, como o Passenger não expõe uma variável de configuração para alterar o tempo limite, você não pode fornecer uma página 504 personalizada.

Depois de ativar intercept_errors no Nginx, você não poderá mais gerar seu     próprias páginas de erro para, por exemplo Códigos HTTP 500, 403, etc. Você tem que definir estática     páginas para esses erros no Nginx também. Essa limitação será levantada em um     versão futura dos serviços.

Fonte: link

Caso contrário, confira esta página em link que fornece um tutorial decente sobre ele. [Embora eu recomende traduzir a página pelo Google Chrome ...]