Я пытаюсь настроить 1.12.2
обратный прокси-сервер nginx для использования auth_request
и proxy_cache
аутентификации запросов к микросервису. Конечные пользователи отправляют простой Bearer
токен со своим запросом, а сервер пытается извлечь с его помощью ресурс, чтобы определить, разрешено ли им продолжить. Извлечение этого ресурса должно быть кэшировано для данного токена, чтобы снять нагрузку с конечной точки аутентификации. Вот моя конфигурация на данный момент:
ssl_certificate /etc/nginx/ssl/certificate;
ssl_certificate_key /etc/nginx/ssl/key;
proxy_cache_path /var/cache/nginx/auth_cache levels=1:2 keys_zone=auth_cache:1m max_size=1g inactive=60m;
server {
listen 80;
listen 443 ssl;
server_name myapi.mydomain.com;
location / {
proxy_pass http://myapi/;
auth_request /auth;
}
location = /auth {
internal;
proxy_pass https://authendpoint.mydomain.com/api/user/verify;
proxy_cache auth_cache;
proxy_cache_key "$http_x_auth_token$request_uri";
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
С точки зрения клиента это работает отлично, но когда я смотрю на сервер nginx, в папку кэша ничего не записывается. Папка /var/cache/nginx/auth_cache
создается, но всегда пустая. Что я мог упустить?
обновлять
Пробуя это с новым nginx ( 1.17.9
, в настоящее время), мы все еще не видим ничего записанного в папку кэша. Где-то я видел предположение, что куки могут блокировать кэширование - это приложение не использует куки, но мы все равно попробовали:
location = /auth {
internal;
proxy_pass http://authservice/api/user/verify;
proxy_cache auth_cache;
proxy_cache_key "$http_x_auth_token$request_uri";
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
proxy_hide_header Set-Cookie;
proxy_ignore_headers Set-Cookie;
proxy_set_header Cookie "";
}
Поведение по-прежнему то же самое: папка auth_cache создается, но туда ничего не записывается, и запросы к нашей конечной точке аутентификации не кэшируются.
Для справки: результаты нашей конечной точки аутентификации крайне минимальны:
< HTTP/1.1 200 OK
< Date: Sun, 12 Apr 2020 18:04:08 GMT
< Server: Kestrel
< Content-Length: 0
Мы также упростили удаленную конечную точку аутентификации с тех пор, как я изначально задал этот вопрос. Теперь это простой http
ресурс, работающий внутри того же кластера, что и процесс nginx. Я обновил пример выше, чтобы отразить это.
последнее обновление
На тот случай, если кто-то еще попытается использовать это в качестве справочного материала, в дополнение к двум полезным ответам ниже, нам нужно было исправить ключ кэша в примере выше:
proxy_cache_key "$http_x_auth_token$request_uri";
Имеет смысл только если вы действительно используете X-Auth-Token
как заголовок, а не просто Authorization
. Ключ выше будет работать, но это означает, что первый проксированный ответ аутентификации для любого uri будет кэширован, а фактический токен будет проигнорирован. На самом деле, нам нужно было:
proxy_cache_key "$http_authorization$request_uri";
решение1
Попробуйте обновить NGINX.
У меня была та же проблема с версией 1.14.0, где ручные запросы к /auth с помощью curl кэшировались, а подзапросы auth_request — нет.
После обновления до NGINX 1.16.1 все заработало.
решение2
Я не могу оставлять комментарии, так как я новичок, но proxy_ignore_headers может вам помочь.
proxy_ignore_headers Expires Cache-Control;
Согласно документации Nginx: Отключает обработку определенных полей заголовка ответа от прокси-сервера.
Если ваш сервер приложений возвращает какие-либо инструкции «без кэширования», Nginx будет их соблюдать, игнорируя эти заголовки, все инструкции кэширования игнорируются.
Также, каков статус кэша в заголовках http-ответа от Nginx на клиентской машине. BYPASS заставит nginx не кэшировать его.
Еще раз извините, что не могу оставить комментарий, но я хотел бы помочь, если смогу.