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

[Dzmitry Stremkouski]

Здравствуйте.

Я установил nginx и модуль Максима Дунина (ngx_http_auth_request_module)
Настройку этого модуля производил по README от модуля.
Сам вебсервер собрал с такими параметрами в дебиане:

nginx version: nginx/1.3.14
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-ipv6 --with-mail --with-mail_ssl_module
--add-module=/usr/build/nginx-upstream-fair-master --with-http_spdy_module
--add-module=/usr/build/ngx_http_auth_request_module

Предисловие для понимания возможности проявления архитектурной ошибки у
меня.
Я разработал модуль авторизации по pin+token поверх google authenticator
http://sourceforge.net/projects/simsim/
Он работает хорошо. Возвращает по локейшну /auth/ или 200 или 401 в разных
случаях.
Алгоритм проекта прост.
1) Клиент приходит в локейшн /auth/ без кук или с просроченными/неверными и
получает 401, предлагает перейти на /gauth/
2) /gauth/ выдаёт запрос basic auth на ввод данных. Данные обрабатывает
моим модулем. Если пара пин-токен подходящая, то
клиенту выдаются куки и его редиректят на /auth/ снова.
3) /auth/ получает куки и возвращает 200.
4) В последующие запросы браузер вставляет куки и прохождение /auth/
просиходит по их наличию без переходов на /gauth/
Проверка куки происходит совместно с обращением в редис, который их хранит..

Чтобы удалённо пользоваться своими проектами, я на фронте сделал reverse
proxy средствами nginx.
Запрос приходит на https://ssl.stremki.net/project_name/
Пример обработки локейшна:

  location /nagios {
    auth_request            /auth/;
    proxy_pass              http://192.168.125.47;
    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;
    proxy_redirect          off;
  }

/auth/ локейшн описан по докумментации от Максима методом проксирования.
  location /auth/ {
    proxy_pass              http://192.168.125.35/auth/;
    proxy_pass_request_body off;
    proxy_buffering         off;
    proxy_cache             off;
    proxy_set_header        Content-Length "";
    proxy_set_header        Host 192.168.125.35;
  }

Я пытался делать без проксирования, указывая URI
auth_request http://192.168.125.35/auth/
Но это не работало и я в логах nginx видел ошибку
2013/11/01 23:31:51 [error] 10938#0: *245 "/usr/local/nginx/htmlhttp://
192.168.125.35/auth/index.html" is not found (2: No such file or
directory), client: 192.168.125.47, server: ssl.stremki.net, request: "GET
/mail/ HTTP/1.1", subrequest: "http://192.168.125.35/auth/", host: "
ssl.stremki.net"

Было бы здорово, если бы я смог работать без проксирования /auth/.
Просто, пока не понял, как прописать внутренний бекенд для обработки и
сейчас
пользуюсь локейшном /auth/ в режиме проксирования.

Для наджиоса всё работает отлично.
Однако, есть точно такие же локейшны для ownCloud и RoundCube

Во время захода на https://ssl.stremki.net/mail/
nginx обрабатывает auth_request
Поскольку, cookie достаточную для прохождения /auth/ я посылаю, то я
получаю страницу логина в RoundCube.
Страница прогружается вся (все элементы: js скрипты, картинки).
Затем, когда я ввожу логин и пароль к RoundCube, браузер впадает в ожидание
ответа от nginx
В tcpdump на бэкенде, отвечающем за /auth/ я не вижу запросов в этот момент.

Для дополнительного тестирования, я поставил на клиентскую часть Burp Proxy
и пошагово прошёл весь процесс авторизации
От получения кук для /auth/ до попадания в вебинтерфейс уже самого ящика в
RoundCube.
И был удивлён. Так, как Burp запрашивает разрешение на каждый шаг (каждый
запрос), как дебаггер, то это даёт временные
промежутки между запросами браузера к nginx.
Если браузер делает запросы не моментально, а через промежутки 1-2 секунды,
то авторизация RoundCube отрабатывает и я
попадаю в почтовый ящик.

Я пока не очень хорошо знаю, как работает nginx во время проксирования
вкупе с модулем Максима и предполагаю, что он
не делает запрос к бекенду, отвечающему за локейшн /auth/ при большом
количестве запросов.
Возможно, я что-то не так настроил.

Помогите, пожалуйста, разобраться.
Спасибо.

-- 
<pre>
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
</pre>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20131102/b7216d3f/attachment.html>