Jenkins/Nginx - Двойной запрос на базовый auth, почему? Почему существует внутренний Jenkins auth?

Question

Ниже представлен мой конфигурационный файл nginx для Jenkins. Большая часть из них точно соответствует тому, что я прочитал в документации.

Файл конфигурации:

upstream app_server { 
    server 127.0.0.1:8080 fail_timeout=0; 
} 

server { 
    listen 80; 
    listen [::]:80 default ipv6only=on; 
    server_name sub.mydomain.net; 

location ^~ /jenkins/ { 

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    proxy_set_header Host $http_host; 
    proxy_redirect off; 

    if (!-f $request_filename) { 
     proxy_pass http://app_server; 
     break; 
    } 

    auth_basic "[....] Please confirm identity..."; 
    auth_basic_user_file /etc/nginx/.htpasswd; 
} 

}

При переходе к http://sub.mydomain.net/jenkins я получаю запрошен моей базовой аутентификации с сервером говорит: [....] Пожалуйста, подтвердите, определить ....

Это правильно, но, как скоро я ввожу правильные учетные данные я затем получить побудивших СНОВА для базовой аутентификации еще раз, но на этот раз: говорит Сервер: Дженкинс.

Где находится этот второй скрытый basic_auth? Это не имеет никакого смысла для меня.

Удар CANCEL на первой строке я тогда правильно получить разрешение на 401 требуется ошибку.

задерживаясь ОТМЕНА на второй базовой аутентификации («Сервер говорит: Дженкинс») я получаю:

HTTP ERROR 401 

Problem accessing /jenkins/. Reason: 

Invalid password/token for user: _____ 
Powered by Jetty:// 

Кто-нибудь знает, что это, возможно, происходит?

Answer 1

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

Решения было ответа здесь: https://serverfault.com/questions/511846/basic-auth-for-a-tomcat-app-jira-with-nginx-as-reverse-proxy

линии я пропускал от моей конфигурации Nginx был:

# Don't forward auth to Tomcat 
proxy_set_header Authorization ""; 

силу по умолчанию, оказывается, что после основной аутентификации Nginx дополнительно пересылают AUTH заголовки Дженкинса, и именно это и привело к моей проблеме. Дженкинс получает перенаправленные заголовки auth, а затем думает, что ему тоже нужно авторизоваться ?!

Если мы установим обратный прокси-сервер, чтобы не пересылать какие-либо заголовки полномочий, как показано выше, все работает так, как должно быть. Nginx предложит basic_auth, и после успешного авторизации мы явно очистим (сброс?) Заголовки auth при пересылке на наш обратный прокси.

Answer 2

У меня тоже была эта проблема, в моем случае это было вызвано тем, что безопасность включена в самом дженкинсе, отключив безопасность, разрешив проблему.

По их документы:

Если вы контроля доступа в Apache, не дают возможности безопасности в Дженкинс, так как эти две вещи, которые будут мешать друг другу.

https://wiki.jenkins-ci.org/display/JENKINS/Apache+frontend+for+security

То, что кажется, происходит то, что Nginx направляет auth_basic ответ на Дженкинс, который пытается выполнить auth_basic в ответ. Я еще не нашел удовлетворительного решения проблемы.