Мобильная версияСейчас я разрабатываю веб-приложение Symfony, для которого у меня есть сервер nginx для тестирования и производства. Мой API, над которым я сейчас работаю, должен использовать токены Bearer для авторизации.
Мой рабочий сервер находится под https://api.mydomain.de, а моя тестовая среда находится в https://dev.api.mydomain.de
На данный момент я настроил базовую систему аутентификации следующим образом:
Код: Выделить всё
location / {
try_files $uri /index.php$is_args$args;
auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/passwd/dev_passwd.txt;
}
Но при тестировании моего пользователя системе я понял, что это не будет работать так хорошо, как я думал, когда мое приложение также пытается выполнить аутентификацию с использованием заголовка.
Это означает, что я либо запрашиваю сервер, используя действительные учетные данные для входа в приложение , но nginx не одобряет мой запрос или наоборот.
Что я пробовал
У меня было несколько идей, как это исправить, но я не был уверен, как их реализовать и даже какой из них выбрать:
1. Проверьте токен носителя с помощью auth_request
Я рассматривал возможность использования директивы auth_request для проверки токена носителя, выполнив подзапрос к конечной точке, например /user/validate-token/{ токен}. Я столкнулся с проблемами, связанными с тем, что блок auth_request не допускался внутри операторов if, и мне пришлось столкнуться с 502 ошибками, которые я не смог исправить.Вот что у меня было на данный момент:
Код: Выделить всё
location / {
try_files $uri /index.php$is_args$args;
# Check if the Authorization header contains a Bearer token
if ($http_authorization ~* ^Bearer\s+(.*)) {
set $bearer_token $1;
# Use an internal location to validate the token
auth_request /internal/token-validation;
}
auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/passwd/dev_passwd.txt;
}
location = /internal/token-validation {
internal;
proxy_pass http://localhost/user/validate-token/$bearer_token;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
}
# Maybe remove auth_basic here ?
location /user/validate-token {
try_files $uri /index.php$is_args$args;
auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/passwd/dev_passwd.txt;
}
error_page 401 = @error_401;
location @error_401 {
return 401 "Unauthorized";
}
2. Использование внутренних расположений/маршрутов в nginx
Я также подумал о создании отдельных внутренних расположений для обработки базовой аутентификации и проверки токена носителя. Это позволило бы мне сохранить логику чистой и отдельной, но я столкнулся с аналогичными проблемами. Кроме того, мое приложение распознавало все URL-адреса запросов как /basic_auth или /validate_bearer_token, поскольку запрос был переписан внутри.Вот что у меня было:
Код: Выделить всё
location /basic_auth {
auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/passwd/dev_passwd.txt;
rewrite ^/basic_auth(/.*)$ $1 break;
try_files $uri $uri/ /index.php?$query_string;
}
location ~ ^/validate_bearer_token/(.*) {
internal; # Internal only, not accessible from outside
set $auth_token $1;
# Pass the request to the validation endpoint
proxy_pass http://127.0.0.1/user/validate-token/$auth_token;
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_set_header X-Forwarded-Proto $scheme;
# Intercept errors to handle token validation response
proxy_intercept_errors on;
error_page 401 = @error_401;
# I couldn't use 200 for some reason
error_page 399 = @auth_success;
}
# [...]
3. Переименование заголовка авторизации в моем приложении
Я также рассмотрел возможность переименования заголовка авторизации в моем приложении, чтобы избежать конфликтов между базовой аутентификацией и аутентификацией на основе токена. Однако я не был уверен, что это лучший способ решить эту проблему, а также не знал, как это сделать, поскольку я использую Symfony с LexikJWTBundle, который ожидает стандартный заголовок авторизации. формат. Я не знаю, усложнит ли это интеграцию и может ли привести к дальнейшим проблемам в будущем? Возможно ли это вообще?4. Не использовать базовую аутентификацию
Другой подход, о котором я подумал, заключался в том, чтобы иметь своего рода заголовок пароля, который действует вместо заголовка Authorization Basic и проверяется моим приложением Symfony, а не самим nginx. . Однако я также вижу, какие проблемы это вызывает, особенно при тестировании моего интерфейса на https://dev.mydomain.de, но я также открыт для этого решения.Я был интересно узнать, какое из этих решений объективно лучше всего использовать или я что-то упустил?
Подробнее здесь: https://stackoverflow.com/questions/791 ... -my-webapp
