我有一个NGINX反向代理,它还使用以下配置提供静态内容
location / {
auth_request /authn;
proxy_intercept_errors on;
recursive_error_pages on;
error_page 301 302 303 307 308 = @handle_redirect;
gzip_static on;
index index.html;
root /usr/share/nginx/html;
try_files $uri $uri/ @index;
}
location /authn {
set $target http://gateway:8030/authn;
proxy_pass http://gateway:8030/authn;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
proxy_pass_request_headers on;
proxy_intercept_errors on;
recursive_error_pages on;
error_page 301 302 303 307 308 @handle_redirect;
}
location @handle_redirect {
proxy_set_header Host $host:$server_port;
set $redirect_url $upstream_http_location;
proxy_pass $redirect_url;
}
目标是将用户通过子请求身份验证到/authn端点,如果用户不是,该端点将返回302和位置标头。但是客户端通过错误日志从NGINX获得500,如
auth request unexpected status: 500 while sending to client
我还有一个/root端点,它直接传递给/authn网关,它正确地重定向到登录页面并验证客户端。我尝试过,而不是处理子请求中的重定向代理传递请求到这个端点,设置
location /root {
set $target http://top-gateway:8030/authn;
proxy_pass http://top-gateway:8030/authn;
}
location /authn {
...
error_page 301 302 303 307 308 /root;
但在这种情况下我得到了500
auth request unexpected status: 302 while sending to client
在NGINX error.log
为什么NGINX不能用这个设置正确地处理重定向,以及如何正确地解决这个问题?
发布于 2022-02-02 19:27:53
也许这对你是有用的,为了知道它失败的原因,也许我迟到了,但我发现这条线索可以做一些类似的事情。
该链接显示了Nginx开发人员与一个用户之间的对话,该用户有编写补丁的动机。看起来Nginx只支持auth_request的2xx和4xx代码。但是,如果您控制应用程序(如该链接中所示),您可以这样做。
location / {
auth_request /auth;
auth_request_set $auth_redirect $upstream_http_location;
error_page 401 = /auth_redirect;
}
location /auth {
proxy_pass http://auth_backend;
...
}
location /auth_redirect {
return 302 $auth_redirect;
}
对我来说,阅读这篇文章也很有用(不一样,只是一些想法的线索):
How do I make web service calls within nginx?
这个链接展示了一个关于auth_request_set的简单介绍(您可以在文档中找到它)。
auth_request_set $x_upstreamhost $upstream_http_x_upstreamhost;
此外,下面是auth_request代码实现的深层内容。
https://www.nginx.com/resources/wiki/extending/examples/auth_request/
此链接显示了auth_request实现的代码分解。我不能把它包括在这里。
干杯,
https://stackoverflow.com/questions/61055383
复制相似问题