一 ngx_http_access
① 基本描述
场景: 限制某些'ip来源'的访问;基于'ip'进行限制
细节点: 基于'$remote_addr'进行判断的
② allow deny
③ 官方案例
说明: 按照配置文件中'allow|deny'的先后顺序,只要匹配上则'停止'继续匹配
④ 经典应用场景
+++++++++++ '只允许192.168.1.100访问,其余都拒绝' +++++++++++
allow 192.168.1.100;
deny all;
+++++++++++ '只拒绝192.168.1.100访问,其余都允许' +++++++++++
deny 192.168.1.100;
allow all;
⑤ 补充
补充: 'ip被禁止'之后会返回'403'状态码
二 auth_basic
源码分析
① 基本描述
说明:校验'username'和'passwd'是否匹配,来决定是否拒绝访问
注意点: openresty默认'没有'将http_auth_basic_module编译进去
② auth_basic
③ auth_basic_user_file
④ 交互原理
说明:如果是'http'协议就是'明文'传输的,建议使用'https'
⑤ 密码文件生成
1)使用htpasswd生成密码 -->'最简单(增删改),但是系统不一定有httpd-tools工具'
2)使用openssl生成密码 -->'推荐'
3)使用python生成密码 -->'了解'
备注: 密码文件最好以'隐藏'文件的形式,并注意'权限'和'属性'
1)openssl passwd
2)htpasswd
细节点:htpasswd的密码文件'不是base64编码'
密码文件:建议命名格式'.basic_auth.db'
⑥ 典型应用场景
1)背景:只要用户在浏览器输入,就可以访问监控页面;这样'很不安全',因为任何人都可以'访问'这个页面
2)是否可以再添加一个'授权模块'呢?监控nginx服务器'运行情况'的模块
⑦ 案例讲解
说明: 本文以'变量'的形式,只是告诉'可以'这样用,要根据'具体场景'使用
1)未使用变量可能存在500的报错
2)使用变量,但实际密码文件不存在报错403
3)案例3
4)正常浏览器访问
细节点: 清除'历史'的登陆记录 -->'ctrl+shift+delete'
5)通过Authorization请求头进行认证
三 auth_request模块
auth_request源码分析
① 概述
使用'第三方'做权限控制: 提供更'复杂'的用户密码权限验证
细节点: 对于'子请求返回的401'错误,客户端还从'子请求响应'中接收"WWW-Authenticate"响应头
补充: auth_request'支持grpc、ws'等协议
② auth_request
生成一个'子请求',这个子请求会'访问这个uri'
③ auth_request_set
应用场景: 把上游'认证失败的原因'记录到内部日志中,对外'统一'用固定的页面展示
效果: 相当于在'auth_request'模块作用的'access'阶段set一个'变量',透传给后续的'请求阶段'
④ 案例讲解
1)源码编译
2)nginx配置
说明: 在'location /private/'配置'proxy_pass'表示正确认证后,把请求转发的业务服务,这里'省略'了直接用代理层的nginx的index.html作为展示
3)认证服务器配置1
4)认证服务器配置2
⑤ 搜集的案例汇总
新老系统的迁移
携带Content-Length请求头导致auth_request不生效
auth_request跨域的问题
auth_request集成ldap
auth_request 模块实现自定义认证界面
⑥ 补充解读
[1]、可以帮助我们实现对资源的'统一'权限验证,这在'微服务'中非常有用
[2]、我们可以实现自己的权限认证服务,将所有的资源的请求都'通过权限认证服务后'再进行处理,提高了系统的安全性
[3]、但同时会增加请求的'响应'时间,因为此时每次请求都会发起'两次'http调用
⑦ 相关的思考
四 框架内置的staisfy
① 基本概述
② 指令解读
场景:如果用了'多个http模块'做access访问控制的话,并且需要做"与&"以及"或"这种逻辑操作时,才用得上的
③ 思考1
解读: 不会生效,因为'return'是rewrite阶段,在access之前
④ 思考2
⑤ 思考3
说明: 'allow all'属于access_module,'优先级'最高
⑥ 补充
遗留:还有哪些'第三方'的access模块