Вопрос или проблема
У меня есть nginx в качестве обратного прокси. Прокси требует аутентификации с использованием Authorization Basic. Я могу нормально получить доступ к проксируемому серверу, пока не дойдет до запроса /api/config/config_entries/flow. API требует заголовка Authorization Bearer, который отправляется браузером. Проблема в том, что прокси отказывает в запросе, потому что у него больше нет Authorization Basic. Как я могу заставить nginx передавать Bearer токен и игнорировать его сам?
Nginx показывает такие логи:
2024/11/24 20:08:46 [info] 55109#100183: *26059 не предоставлены имя пользователя/пароль для базовой аутентификации, клиент: xxx.xxx.xxx.xxx, сервер: myserver.com, запрос: "POST /api/config/config_entries/flow HTTP/1.1", хост: "myserver.com", ссылщик: "https://myserver.com/config/integrations/dashboard"
2024/11/24 20:08:46 [info] 55109#100183: *26059 задержка несанкционированного запроса, клиент: xxx.xxx.xxx.xxx, сервер: myserver.com, запрос: "POST /api/config/config_entries/flow HTTP/1.1", хост: "myserver.com", ссылщик: "https://myserver.com/config/integrations/dashboard"
2024/11/24 20:11:50 [info] 55109#100183: *26086 клиент закрыл соединение во время ожидания запроса, клиент: xxx.xxx.xxx.xxx, сервер: 0.0.0.0:443
Мой файл nginx.conf выглядит так:
server {
listen 443 ssl;
server_name myserver.com;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
ssl_certificate /path/fullchain.pem;
ssl_certificate_key /path/privkey.pem;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers CDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
auth_basic "Нет";
auth_basic_user_file htpasswd;
auth_delay 5s;
location / {
proxy_pass http://proxied_server/;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
Ответ или решение
Проблема с проксированием и авторизацией в NGINX: решение
В данной ситуации вы столкнулись с проблемой, связанной с использованием NGINX в качестве реверс-прокси, который требует базовую аутентификацию (Basic Auth) и пускает запросы, содержащие заголовок авторизации Bearer. Это достаточно распространённая ситуация, и чтобы её решить, необходимо корректно настроить NGINX для обработки двух различных типов авторизации.
Суть проблемы
Ваши логи NGINX указывают на то, что запрос к URL /api/config/config_entries/flow
не проходит проверку пользовательского имени и пароля, требуемую базовой аутентификацией, так как заголовок Authorization не передается на проксируемый сервер. При этом клиент отправляет заголовок Authorization Bearer, который NGINX игнорирует, так как обрабатывает только Basic Auth.
Решение
Чтобы разрешить NGINX игнорировать заголовок Authorization Basic и передавать Bearer токен, необходимо внести изменения в конфигурацию NGINX. Один из подходов заключается в установлении условий для того, чтобы NGINX пропускал запросы с определёнными URI без проверки базовой аутентификации.
Шаги по настройке:
- Настройка Location для Исключения Аутентификации:
Вам нужно добавить отдельный блокlocation
для обработки конкретного пути/api/config/config_entries/flow
, который будет пропускать авторизацию.
location /api/config/config_entries/flow {
proxy_pass http://proxied_server/;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# Передаем Bearer токен, если он существует
proxy_set_header Authorization $http_authorization;
}
- Обновление Базовой Аутентификации для Остальных Запросов:
Убедитесь, что вызывается базовая авторизация только для остальных запросов. Это означает, что данный блокlocation
должен быть размещён над общим правиломlocation /
.
server {
listen 443 ssl;
server_name myserver.com;
ssl_certificate /path/fullchain.pem;
ssl_certificate_key /path/privkey.pem;
auth_basic "Nope";
auth_basic_user_file htpasswd;
location /api/config/config_entries/flow {
proxy_pass http://proxied_server/;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Authorization $http_authorization; # Передаем токен Bearer
# Исключите базовую аутентификацию для этого пути, используя lua или другие решения, если необходимо
}
location / {
proxy_pass http://proxied_server/;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
Дополнительные рекомендации
-
Безопасность заголовков: Убедитесь, что заголовок Authorization Bearer адекватно защищён и обновляется, чтобы избежать утечек токенов через другие ресурсы (например, кэширование).
-
Логи и мониторинг: Настройте логи для мониторинга запросов, чтобы убедиться, что аутентификация проходит успешно. Это позволит вам отслеживать и выявлять потенциальные проблемы в будущем.
-
Тестирование изменений: Обязательно протестируйте все настройки в тестовой среде, прежде чем переносить их на продуктивный сервер.
Следуя этим шагам, вы сможете настроить NGINX так, чтобы он не мешал передаче Bearer токена и при этом поддерживал базовую аутентификацию для всех остальных запросов.