Nginx http_auth_request_module 统一用户验证权限验证

最新推荐文章于 2025-03-07 22:10:18 发布

富士康质检员张全蛋

最新推荐文章于 2025-03-07 22:10:18 发布

阅读量7.9k

点赞数 3

分类专栏： Nginx 文章标签： nginx

本文链接：https://blog.csdn.net/qq_34556414/article/details/105809958

版权

Nginx 专栏收录该内容

93 篇文章

订阅专栏

auth_request与access|auth_basic比较

无论是通过access模块限制IP还是通过auth_basic模块设置用户名密码，这些都是非常简单的用户验证方式。

在生产环境当中很可能会有动态web服务器，它们通过更加复杂的用户名密码权限验证。这个时候可以通过访问nginx资源时候，先将用户的去请求传递给这样的应用服务器，根据应用服务器返回的结果再判断请求资源能不能继续执行。在access阶段有一个auth_request模块，该模块就可以完成这样的功能。

可以通过合理配置Nginx的auth_request模块来实现对敏感路径下的内容进行访问限制（通过auth_request来进行的权限限制）。该模块默认是不会编译到Nginx中的需要手动添加--with-http_auth_request_module

auth_request原理语法

原理：收到请求后，先将该请求hold住，生成子请求，子请求和该请求内容是相同的。通过反向代理技术把子请求传递给上游服务，根据上游服务的响应再来决定是否处理当前的请求。

功能：向上游的服务器转发请求，若上游服务器返回的响应码是2XX，则继续执行。若上游服务器返回的是401或者403，则将响应返回给客户端。

Syntax: auth_request uri | off;  --加上url会生成一个子请求，这个子请求会访问该url，根据该url返回的结果来决定是否允许该请求向下继续执行
Default: auth_request off;
Context: http, server, location

Syntax: auth_request_set $variable value;  --根据返回的结果设置变量来做进一步处理
Default: —
Context: http, server, location

举个例子如下

服务器A(192.168.179.99)，其路径/上存有敏感信息，其他路径可公开访问。
服务器B(192.168.179.100)，为认证服务器，其上部署了本项目代码。

服务器A(server1)的Nginx配置文件：

location / {
     auth_request /test_auth;  --生成子请求会去访问location = /test_auth{}
 } 

location = /test_auth{
     proxy_pass http://192.168.179.100/auth_upstream;  --反向代理到后端auth_upstream
     proxy_pass_request_body off;
     proxy_set_header X-Original-URI $request_uri;
}

[root@localhost ~]# echo "proxy back this is 192.168.179.99" > /usr/local/nginx/html/index.html   --该条记录用来验证用户在后端192.168.179.100返回状态

（1）服务器B(server2)的Nginx配置文件：

server{
      listen  80;
      access_log  logs/host.log  main;
      charset utf-8;
      location /auth_upstream{
      return 200 'auth success';
     }

[root@localhost ~]#  curl -I 192.168.179.99
HTTP/1.1 200 OK
Server: nginx/1.16.1
Date: Wed, 29 Jul 2020 02:12:48 GMT
Content-Type: text/html
Content-Length: 42
Last-Modified: Sat, 04 Jul 2020 01:28:06 GMT
Connection: close
ETag: "5effdb26-2a"
Accept-Ranges: bytes

如果用户为合法用户：
那么服务器B将会生成session，并通过Set-cookie命令告知用户浏览器。用户通过此Cookie即可获得服务器B的认可授权。当用户通过此Cookie访问服务器B中的/auth_upstream目录时，会返回200的状态码。

（2）服务器B(server2)的Nginx配置文件：

server{
      listen  80;
      access_log  logs/host.log  main;
      charset utf-8;
      location /auth_upstream{
      return 403 'auth failed';
     }
}


[root@localhost ~]#  curl -I 192.168.179.99
HTTP/1.1 403 Forbidden
Server: nginx/1.16.1
Date: Wed, 29 Jul 2020 02:14:12 GMT
Content-Type: text/html
Content-Length: 153
Connection: close

如果用户为非法用户：
那么服务器B将不会session，由于用户无法获得认可的Cookie，那么当用户再次访问/auth_upstream的路径时，服务器会返回403错误。

总结

以上，通过auth_request模块以及相关配置就实现了对敏感内容的访问限制。而且通过第三方的机制，也无需自己手工实现登录功能。同时，此方案可以对同一域名下的不同子域名中的内容进行访问限制。可以重复利用一个登录系统，服务于多个其他系统。（auth_request模块对于我们拥有一个统一的用户健全系统是非常有用的）