深入了解Nginx auth_request
模块
nginx-auth-request-module
该模块是nginx一个安装模块,使用配置都比较简单,只要作用是实现权限控制拦截作用。默认高版本nginx(比如1.12)已经默认安装该模块,下面介绍下使用该模块实现多个站点之间的统一权限控制。
例子1
这里用一个例子来说明下,如下例子是包含site1(对应web1)、site2(对应web2)、auth(20.131:7001)在内的三个应用项目,auth项目主要做权限拦截,比如jwt校验等,site1、site2分别为两个受保护的资源站点,只有auth授权通过后才能访问该站点。
实现上述要求nginx配置详情如下(nginx地址为20.198):
upstream web1 { server 192.168.20.131:3000; } upstream web2 { server 192.168.20.131:3001; } server { listen 80; server_name localhost; #charset koi8-r; #access_log /var/log/nginx/host.access.log main; location / { root /usr/share/nginx/html; index index.html index.htm; } location /api/web1 { auth_request /auth; error_page 401 = @error401; auth_request_set $user $upstream_http_x_forwarded_user; proxy_set_header X-Forwarded-User $user; proxy_pass http://web1; } location /api/web2 { auth_request /auth; error_page 401 = @error401; auth_request_set $user $upstream_http_x_forwarded_user; proxy_set_header X-Forwarded-User $user; proxy_pass http://web2; } location /auth { internal; proxy_set_header Host $host; proxy_pass_request_body off; proxy_set_header Content-Length ""; proxy_pass http://192.168.20.131:7001/auth; } location @error401 { add_header Set-Cookie "NSREDIRECT=$scheme://$http_host$request_uri;Path=/"; return 302 http://192.168.20.131:7001/login; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } }
配置好之后,要明白一点,那就是nginx-auth-request-module模块基本使用原理就是:
1、auth_request对应的路由返回401 or 403时,会拦截请求直接nginx返回前台401 or 403信息;
2、auth_request对应的路由返回2xx状态码时,不会拦截请求,而是构建一个subrequest请求再去请求真实受保护资源的接口;
所以,基于此,auth模块只需要校验然后返回相应的状态码即可实现权限拦截操作,简单测试如下:
auth代码:
// 授权认证接口 async auth() { console.log(Date.now()); this.ctx.status = 200; } // 失败后的登录页面 async login() { console.log('失败了........'); this.ctx.body = { msg: '授权失败', code: 10001 } }
这里的auth授权接口我们直接返回200,login是上述auth项目下配置的路由,用于授权失败后302至登录页面用的。
site1和site2代码相同,只罗列一个如下:
/* /api/web1/users,如果是web2则为/api/web2/users */ router.all('/', function(req, res, next) { res.send('respond with a resource from web1'); });
这里只是简单渲染输出一个字符串而已,测试如下:
浏览器访问:http://192.168.20.198/api/web1/users,输出:
改变auth接口如下:
// 授权认证接口 async auth() { console.log(Date.now()); this.ctx.status = 401; } // 失败后的登录页面 async login() { console.log('失败了........'); this.ctx.body = { msg: '授权失败', code: 10001 } }
这里将状态码改为了401,再次访问:http://192.168.20.198/api/web1/users,输出:
这里可以看到,浏览器直接进行了302跳转,因为鉴权失败,直接重定向到登录页面了。
以上就是关于nginx-auth-request-module模块的基本操作及配置,多个项目下部署统一的权限接口时还是相当有用的。
例子2
首先,确保Nginx已经安装并启用了auth_request模块。然后,编辑Nginx配置文件(通常是nginx.conf或某个虚拟主机配置文件)。
通过–with-http_auth_request_module添加auth_request模块
http { # 定义认证服务的逻辑 server { listen 127.0.0.1:8080; location /auth { # 此处为简单示例,实际应用中应调用外部认证服务 if ($http_authorization = "Basic dXNlcm5hbWU6cGFzc3dvcmQ=") { # 假设认证使用Basic Auth return 200; } return 401; } } server { listen 80; server_name example.com; location / { # 使用 auth_request 调用认证服务 auth_request /auth; # 处理认证服务的响应结果 error_page 401 = @error401; error_page 403 = @error403; # 正常处理请求 proxy_pass http://backend; } # 定义认证失败时的处理逻辑 location @error401 { return 401 "Unauthorized"; } location @error403 { return 403 "Forbidden"; } # 认证服务的代理设置 location /auth { proxy_pass http://127.0.0.1:8080/auth; proxy_pass_request_body off; # 不代理请求体到认证服务 proxy_set_header Content-Length ""; proxy_set_header X-Original-URI $request_uri; } } }
配置说明
定义认证服务:
server { listen 127.0.0.1:8080; location /auth { if ($http_authorization = "Basic dXNlcm5hbWU6cGFzc3dvcmQ=") { return 200; } return 401; } }
这个server块模拟了一个简单的认证服务,它监听127.0.0.1:8080,根据请求头Authorization判断用户是否经过认证。在实际应用中,这个应该是一个调用外部服务的代理配置。
主站点配置:
server { listen 80; server_name example.com; location / { auth_request /auth; error_page 401 = @error401; error_page 403 = @error403; proxy_pass http://backend; } location @error401 { return 401 "Unauthorized"; } location @error403 { return 403 "Forbidden"; } location /auth { proxy_pass http://127.0.0.1:8080/auth; proxy_pass_request_body off; proxy_set_header Content-Length ""; proxy_set_header X-Original-URI $request_uri; } }
- auth_request /auth;:该指令告诉Nginx,在处理用户请求前,先将请求发送到/auth进行认证。
- error_page 401 = @error401;和error_page 403 = @error403;:定义认证失败时的处理逻辑,将401或403错误重定向到相应的处理块。
- proxy_pass http://backend;:成功认证后,将请求代理到后端服务器。
认证失败处理:
location @error401 { return 401 "Unauthorized"; } location @error403 { return 403 "Forbidden"; }
认证失败时,根据实际情况返回401或403状态码,并附带相应的错误信息。
测试与验证
启动Nginx,尝试访问http://example.com,并使用不同的Authorization头部测试认证行为。如果头部包含正确的用户名和密码(在本例中为"Basic dXNlcm5hbWU6cGFzc3dvcmQ="),请求应被允许访问后端资源,否则返回相应的错误状态码。
例子3
upstream web1 { server 192.168.20.131:3000; } upstream web2 { server 192.168.20.131:3001; } location ^~ /session/ { charset utf-8; auth_request /session-backend-info/; auth_request_set $backend $upstream_http_backend; proxy_set_header Forwarded $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Port $remote_port; proxy_set_header Host $http_host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_pass $backend/$request_uri; }
$backend为web1、web2 upstream
到此这篇关于深入了解Nginx auth_request的文章就介绍到这了,更多相关Nginx auth_request内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
相关文章
Nginx配置 location模块实现路由(反向代理、重定向)功能
本文主要介绍了Nginx配置 location模块实现路由(反向代理、重定向)功能,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧2022-04-04503 service unavailable错误解决方案讲解
这篇文章主要介绍了503 service unavailable错误解决方案讲解,本篇文章通过简要的案例,讲解了该项技术的了解与使用,以下就是详细内容,需要的朋友可以参考下2021-08-08nginx中配置使用proxy protocol协议的全过程
proxy protocol是一个Internet协议,通过为tcp添加一个很小的头信息,来方便的传递客户端信息,在网络情况复杂又需要获取用户真实IP时非常有用,这篇文章主要给大家介绍了关于nginx中配置使用proxy protocol协议的相关资料,需要的朋友可以参考下2022-04-04
最新评论