Re: Уточнение логики работы ngx_http_auth_request_module

Maxim Dounin mdounin at mdounin.ru
Tue Nov 5 14:08:41 UTC 2013


Hello!

On Tue, Nov 05, 2013 at 02:40:17PM +0400, Dzmitry Stremkouski wrote:

> Максим, спасибо за ваш ответ.
> Я попробовал сделать апгрейд nginx по вашему замечанию, чтобы сузить
> область поиска ошибки.
> 
> На данный момент у меня сборка следующая:
> nginx version: nginx/1.5.6
> built by gcc 4.4.5 (Debian 4.4.5-8)
> TLS SNI support enabled
> configure arguments: --with-openssl=/usr/build/openssl-1.0.1e
> --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
> --http-client-body-temp-path=/var/lib/nginx/body
> --http-fastcgi-temp-path=/var/lib/nginx/fastcgi
> --http-log-path=/var/log/nginx/access.log
> --http-proxy-temp-path=/var/lib/nginx/proxy
> --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug
> --with-http_flv_module --with-http_geoip_module
> --with-http_gzip_static_module --with-http_realip_module
> --with-http_stub_status_module --with-http_ssl_module
> --with-http_sub_module --with-mail --with-mail_ssl_module
> --add-module=/usr/build/nginx-upstream-fair-master --with-http_spdy_module
> --with-http_auth_request_module
> 
> Все симптомы остались прежними.
> CGI скрипты нагиоса работают через такую связку отлично, как и ранее.
> однако, другие приложения (owncloud, roundcube) требуют "медленного"
> прохода.
> Ещё сделал различие, что нагиос работает везде GET запросами, в то время,
> как owncloud, jenkins, roundcube делают периодически POST
> Возможно, это неверно как-то обрабатывается.
> 
> Дополнительно, я попытался смягчить условия для мониторинга, прописал в
> http секцию
> 
>   geo $ip_range {
>     default 0;
>     192.168.125.0/24 1;
>   }
> 
> и в секциях server/location
> 
>   set $auth_location /auth/;
>   if ( $ip_range = 1 ) {
>     set $auth_location /always_ok;
>   }
> 
>   location = /always_ok {
>     return 200;
>   }
> 
>   location /jenkins {
>     auth_request          $auth_location;
>     proxy_pass              http://192.168.125.37:8080;
>     proxy_buffering         on;
>     proxy_set_header        SSL NO;
>     proxy_set_header        Host $host;
>     proxy_set_header        X-Real-IP $remote_addr;
>     proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
>     proxy_read_timeout      1800;
>   }
> 
> такая связка не работает.
> Ошибка в логе всё та же. auth_request зачем-то ищет файл $auth_location а
> не делает подзапрос в локейшн возращаемый переменной.
> 
> 2013/11/05 13:17:13 [error] 32126#0: *1243 open()
> "/usr/local/nginx/html$auth_location" failed (2: No such file or
> directory), client: 185.6.244.255, server: ssl.stremki.net, request: "GET
> /jenkins/login?from=%2Fjenkins%2F HTTP/1.1", subrequest: "$auth_location",
> host: "ssl.stremki.net", referrer: "https://ssl.stremki.net/jenkins/"
> 2013/11/05 13:17:13 [error] 32126#0: *1243 auth request unexpected status:
> 404, client: 185.6.244.255, server: ssl.stremki.net, request: "GET
> /jenkins/login?from=%2Fjenkins%2F HTTP/1.1", host: "ssl.stremki.net",
> referrer: "https://ssl.stremki.net/jenkins/"
> 
> Я включил дебаг для своего адреса. Вот, его вывод.
> http://pastebin.com/aKDG4gYk

Директива auth_request не понимает переменных, и ваша конфигурация 
ожидаемо пытается обратиться к файлу, которого не существует.

Правильное решение исходной задачи "разрешить свою сеть, для 
остальных - требовать авторизацию" - написать что-нибудь вроде:

    location / {
        satisfy any;

        auth_request /auth;

        allow 192.168.125.0/24;
        deny all;

        ...
    }

http://nginx.org/r/satisfy

Что конкретно у вас происходит в случае, когда конфигурация 
работоспособна и помогает "замедление" - надо смотреть, но скорее 
всего просто авторизационный бекенд не справляется с нагрузкой.

-- 
Maxim Dounin
http://nginx.org/en/donation.html



Подробная информация о списке рассылки nginx-ru