Nginx обратный прокси-passthrough базовая аутентификация

Я пытаюсь настроить nginx как обратный сервер rpoxy перед несколькими веб-серверами IIS, которые аутентифицируются с помощью обычной аутентификации.

(Примечание - это не то же самое как nginx, предоставляющий аутентификацию с помощью файла паролей - он должен просто маршелировать everythnig между браузером/сервером)

его рабочий вид выключен-но получение многократного запроса на аутентификацию каждым отдельным ресурсом (image/css и т. д.) На странице.

upstream my_iis_server {
      server 192.168.1.10;
}

server {
    listen       1.1.1.1:80;
    server_name  www.example.com;  

    ## send request back to my iis server ##
    location / {
     proxy_pass  http://my_iis_server;
     proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
     proxy_http_version      1.1;
     proxy_set_header        Connection "";
     proxy_pass_header       Authorization;     
     proxy_redirect off;
     proxy_buffering off;
     proxy_set_header        Host            $host;
     proxy_set_header        X-Real-IP       $remote_addr;
     proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
   }
}

2 ответов


эта точная ситуация заняла у меня целую вечность, чтобы понять, но ОСС такова, я думаю. Этот пост год, так что, может быть, оригинальный плакат понял это или сдался?

в любом случае, проблема для меня по крайней мере было вызвано несколько вещей:

  1. IIS ожидает, что строка области будет такой же, как и то, что она отправила Nginx, но если ваше имя сервера Nginx прослушивает другой адрес, чем восходящий, то серверная сторона WWW-Authenticate не будет тем, что IIS ожидал и игнорировал его.
  2. встроенный модуль заголовка не очищает другие заголовки WWW-Authenticate, особенно проблемный WWW-Authenticate: Negotiate. Использование модуля headers-more очищает старые заголовки и добавляет все, что вы скажете.

после этого я смог, наконец, нажать Sharepoint 2010 через Nginx.

спасибо stackoverflow.

server {
    listen 80;
    server_name your.site.com;

    location / {
            proxy_http_version      1.1;
            proxy_pass_request_headers on;
            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_pass_header      Authorization; //This didnt work for me
            more_set_input_headers  'Authorization: $http_authorization';

            proxy_set_header  Accept-Encoding  "";

            proxy_pass              https://sharepoint/;
            proxy_redirect          default;
            #This is what worked for me, but you need the headers-more mod
            more_set_headers        -s 401 'WWW-Authenticate: Basic realm="intranet.example.com"';
    }
}

у меня были те же симптомы с nginx/1.10.3. У меня есть служба, защищенная базовой аутентификацией, и nginx как обратный прокси-сервер между клиентами и сервером. Требование состояло в том, что nginx будет проходить через разрешение.

первый запрос к серверу прошел через заголовок Authorization. Второй запрос просто заблокировал этот заголовок, что означало, что клиент мог сделать только один запрос за сеанс.

Это было как-то связано с куки. Если Я очистил куки браузера, затем цикл повторяется. Клиент смог аутентифицироваться, но только для первого запроса. Закрытие браузера имело тот же эффект.

решением для меня было изменить вышестоящий сервер с https на http, используя:

proxy_pass http://$upstream;

вместо:

proxy_pass https://$upstream;