![在代理到另一个后端之前检查一个后端的响应](https://linux22.com/image/781972/%E5%9C%A8%E4%BB%A3%E7%90%86%E5%88%B0%E5%8F%A6%E4%B8%80%E4%B8%AA%E5%90%8E%E7%AB%AF%E4%B9%8B%E5%89%8D%E6%A3%80%E6%9F%A5%E4%B8%80%E4%B8%AA%E5%90%8E%E7%AB%AF%E7%9A%84%E5%93%8D%E5%BA%94.png)
我在 Nginx 前端后面的两个位置有两个后端。后端 A 使用 OAuth 实现身份验证。后端 B 没有。
我认为为位置 B 添加身份验证的一种偷懒方法是先将每个请求发送到后端 A。我想到的流程是:
request for /b/kitten.png --> [ nginx ]
[ nginx ] --> request for /index.html --> [backend A]
if A responds 200:
[ nginx ] --> request for /kitten.png --> [backend B]
otherwise return what A returned (redirect to OAuth)
这在 Nginx 中可行吗?如果不行,那么在 OpenResty/HAProxy/Traefik 中可以吗?
答案1
这不是一个完整的答案,但是评论稍微太长了:
您描述的设置在概念上类似于一种相当常见的策略:
- 将身份验证转移到一个系统
- 使用反向代理来强制只有经过身份验证的客户端才能访问您的其他应用程序/后端(通过检查请求)
- 未经身份验证的客户端被反向代理拒绝(和/或理想情况下重定向到来自身份验证提供程序的登录页面,一旦身份验证成功,将重定向回应用程序)
- 经过身份验证的客户端被授予访问权限。
这需要一种方法来验证客户端在反向代理中提交的 header/cookie/session token。优点当然是反向代理暴露的应用程序不必提供自己的登录/身份验证方法。
对于 nginx 来说,一些 lua 代码似乎是创建这种方法的常用方法。
例如 access_by_lua
方法通常用于与 nginx 和 keycloak 作为身份验证提供程序进行集成。请参阅示例:这里和这里