Nginx: limitação de taxa de bypass com cabeçalho

Question

Esta resposta é perfeita com limitação de taxa de bypassing com endereços IP.

Se eu precisar ignorar a limitação de taxa com um cabeçalho secreto, como faço isso?

Ref:

http {
    geo $whitelist {
       default 0;
       # CIDR in the list below are not limited
       1.2.3.0/24 1;
       9.10.11.12/32 1;
       127.0.0.1/32 1;
    }
    map $whitelist $limit {
        0     $binary_remote_addr;
        1     "";
    }
    limit_conn_zone      $limit    zone=connlimit:10m;

    limit_conn           connlimit 5;
    limit_conn_log_level warn;   # logging level when threshold exceeded
    limit_conn_status    503;    # the error code to return

    

Answer 1

A razão usual para essas perguntas é que a maioria dessas diretivas não pode ser usada dentro do contexto da declaração if , portanto, como alguém poderia especificar condicionalmente limites diferentes?

A resposta é usar variáveis intermediárias - assim como na resposta vinculada, use os limites usando variáveis, onde, subsequentemente, os valores dessas variáveis seriam diferentes dependendo de uma declaração map ou if . / p>

http {
    map $http_x_secret_header $limit {
        default      $binary_remote_addr;
        secretvalue  "";
    }
    limit_conn_zone      $limit    zone=connlimit:10m;
    …

Ref:

• link
• link
• link
• link

Answer 2

FWIIW, também procurei na outra resposta "estranha" à pergunta que você vinculou - foi escrita em 2011 , tinha apenas 3 votos positivos mais cedo hoje em 2017, em comparação com 23 votos positivos para a resposta mais recente por volta de 2014 que você cita. Talvez surpreendentemente, a resposta ignorada mais antiga realmente funciona sem problemas também!

Aqui está minha opinião sobre a configuração completa do MVP, totalmente testada:

server {
    listen 7461;
    error_page 429 = @slowdown;
    if ($http_x_secret_header != secret_value) {
        return 429;
    }
    location @slowdown {
        #limit_...
        return 200 "$uri: slowed down\n";
    }
    location / {
        return 200 "$uri: very fast\n";
    }
}

Aqui está o teste para mostrar a você que tudo funciona, incluindo o fato de que o código 200 OK correto é retornado:

%curl -H "X-Secret-Header: secret_value" localhost:7461/important/path/
/important/path/: very fast

%curl -H "X-Secret-Header: wrong_value" localhost:7461/important/path/
/important/path/: slowed down

%curl -v localhost:7461/important/path/ | & fgrep -e HTTP/ -e /important
> GET /important/path/ HTTP/1.1
< HTTP/1.1 200 OK
/important/path/: slowed down
%

Então, sim, o redirecionamento error_page realmente funciona também!

Deixe-me explicar a razão para o estranho error_page resposta - no nginx, você pode fazer tanto externo redirecionamentos (visível para o cliente), bem como < strong> internal redireciona (feito internamente, sem quaisquer respostas intermediárias ao cliente).

Esta diferença interna versus externa é um conceito muito poderoso , sem o qual muitos legal truques não seria possível, uma vez que a linguagem de configuração é simples o suficiente para limitar o número de diretivas disponíveis dentro de uma instrução if , bem como não permitir declarações if aninhadas.

Portanto, com os redirecionados internos, o $uri pode ser alterado internamente, fazendo com que a sua solicitação reflita entre vários locais independentes (pense em cada location como um estado em um DFA (autômato finito determinístico)) , até que um resultado desejado seja alcançado (para um exemplo extremo disso, dê uma olhada no link , como visto em nginx.conf 2016 ).

Para resumir , no exemplo acima:

• reutilizamos o 429 error_page para agir como um internal redirecionado para um internal location e, em seguida, processamos esse internal location da mesma maneira que um não - a localização interna teria sido processada, exceto pela adição de algumas variáveis ou diretivas adicionais;

• também usamos o parâmetro = para a diretiva error_page para instruir o nginx a não enviar a 429 codifique de volta para o cliente, mas deixe o processamento adicional determinar qual deve ser o código de status final.