nginx: почему нет журнала доступа для переопределенного местоположения - PullRequest
0 голосов
/ 17 марта 2020
Файл конфигурации

My nginx выглядит следующим образом:

server {        
    location /mysite {
        auth_request /authVerify;
        proxy_pass http://localhost:4200;
        error_page 401 = /login;
    }

    location /authVerify {
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
        proxy_set_header X-Original-URI $request_uri;
        proxy_pass http://localhost:3000;
    }

    location /login {
        proxy_cookie_path / "/; HttpOnly";
        proxy_pass http://localhost:3000;
    }

    location / {
        root   html;
        index  index.html index.htm;
    }
}

В конфигурациях, связанных с журналом, используются настройки по умолчанию.

работает auth_request конфигурация. Но когда я отправляю запрос на /mysite, в журнале доступа регистрируется только его логирование, нет регистрации /authVerify, хотя он фактически прокси-сервер через эту локацию. Если я отправлю запрос по номеру /authVerify напрямую, будут также входы в систему.

Так в случаях перенаправления, как создать журналы для всех местоположений, через которые проходит запрос?

Обновление На основании комментария я установил log_subrequest на уровне http. После этого изменения были созданы журналы внутреннего переопределения, но журнал исходного местоположения mysite исчезает.

В настоящее время после отправки одного запроса на /mysite журнал выглядит следующим образом:

enter image description here

Я нашел следующее объяснение по nginx do c:

Requests are logged in the context of a location where processing ends. It may be different from the original location, if an internal redirect happens during request processing.

http://nginx.org/en/docs/http/ngx_http_log_module.html

Это из-за этого? Есть еще методы для регистрации всего потока запроса?

1 Ответ

1 голос
/ 18 марта 2020

Вы пробовали включить log_subrequest?

log_subrequest

Context: http, server, and location

Enables or disables logging of sub-requests triggered by internal redirects or SSI requests.

Syntax: on or off

Default value: off
...