Nginx bloqueia o acesso ao url

Question

Estou usando o concrete5 e preciso desabilitar / login no meu site. Nginx é o meu servidor.

Eu tentei até agora para permitir o acesso apenas aos ips especificados:

       location /login {
           allow 5.69.34.213;
           allow 5.80.29.130;
           deny all;
   }

Mas não funcionou. Bloqueia all ips e o especificado também. O que estou fazendo errado?

Atualizar Meu arquivo conf é:

 server {
    listen 80;
    server_name my_website.com;
    return 301 https://my_website.com$request_uri;
}

#HTTPS server

server {
    listen 443 ssl;
    server_name my_website.com;

    root /var/www-staging/my_website/public_html;

    gzip on;
    gzip_proxied any;
    gzip_types text/plain text/html text/css application/json application/javascript application/x-javascript text/javascript text;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/my_website.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/my_website.com/privkey.pem;

    ssl_session_timeout 5m;

    add_header Strict-Transport-Security "max-age=31536000";

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA";
    ssl_prefer_server_ciphers on;

    # mkdir /etc/nginx/ssl
    # openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;

        location /templates {
                alias /var/www-staging/my_website/templates/dist;
        }

    location / {
        try_files $uri /index.php$request_uri;
    }

    location ~ \.php($|/) {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param QUERY_STRING    $query_string;

        fastcgi_intercept_errors on;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock; 
        include fastcgi_params;
    }

    location /login {
        allow 5.80.29.130;
        deny all;
    }

    error_log /var/log/nginx/my_website_error.log;
    access_log /var/log/nginx/my_website_access.log;
}

    

Answer 1

A documentação do nginx explica seu caso: link

nginx first searches for the most specific prefix location given by literal strings regardless of the listed order. In the configuration above the only prefix location is “/” and since it matches any request it will be used as a last resort. Then nginx checks locations given by regular expression in the order listed in the configuration file. The first matching expression stops the search and nginx will use this location. If no regular expression matches a request, then nginx uses the most specific prefix location found earlier.

seguindo esta declaração /login somente coincide se não houver regex correspondente. Se você acessar /login/login.php , por exemplo, seu location ~ \.php($|/) ganhará a eleição de quem receberá essa solicitação.

SOLUÇÃO 1

Para corrigir o problema, defina este local ACIMA DO php location

location ~* /login {
    allow 5.80.29.130;
    deny all;
}

SOLUÇÃO 2

use

location ^~ /login {
    allow 5.80.29.130;
    deny all;
}

O

link explica que ^~ desativa a correspondência de regex se esse local da sequência de caracteres de prefixo corresponder. / p>     

Answer 2

Eu mesmo resolvi o problema. Eu tenho uma máquina vagrant para esse projeto onde eu poderia depurar passo a passo. O PHP estava fazendo uma solicitação de onda para uma API que levaria para sempre . Tive que definir um tempo limite para lidar com esse comportamento:

curl_setopt($ch, CURLOPT_TIMEOUT, 6);
$response = curl_exec($ch);

e agora verifique se $ response se false (sem resultado)

if (!$response) {
        $this->writeFile('FALSE ' . $ip . ' ' . $session);
    } else {
        $this->writeFile('SUCCESS ' . $ip . ' ' . $session);
    }

Isso resolveu o problema. fpm socket foi um erro enganoso. Erro de novato ...

Eu preciso descobrir como falar com essa API, aparentemente os desenvolvedores mudaram algo ontem à noite e provavelmente introduziram um bug. Estava trabalhando todo esse tempo ...

Obrigado pela sua ajuda pessoal.