Здравствуйте. Я установил 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>
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
