forward_auth
一个专用的(opinionated)指令,它会把请求复制给认证网关,认证网关可以决定是否应该继续处理,或者需要跳转到一个登录页面。
Caddy的reverse_proxy能够向外部服务执行“预检查请求”,但此指令专门针对认证用例定制。它实际上只是使用一个更长、更常见配置(如下)的便捷方式。
此指令会把uri重写后,向配置的上游发出GET请求:
- 如果上游响应
2xx状态码,则允许访问,copy_headers中的头字段会被复制到原始请求,并继续处理。 - 否则,如果上游响应任何其他状态码,则上游响应会被复制回客户端。这个响应通常应包含重定向到认证网关登录页面的内容。
如果这并不完全是你想要的行为,可以以下面的扩展形式为基础,按需自定义。
支持reverse_proxy的所有子指令,并将它们传递给底层的reverse_proxy处理器。
语法
forward_auth [<matcher>] [<upstreams...>] { uri <to> copy_headers <fields...> { <fields...> } }
-
<upstreams...> 是要向其发送认证请求的上游(后端)列表。
-
uri 是在发送给上游的请求上设置的URI(路径和查询)。这通常是认证网关的验证端点。
-
copy_headers 是在请求获得成功状态码时,要从响应复制到原始请求的HTTP头字段列表。
可通过
>后接新名称来重命名字段,例如Before>After。如果你更喜欢可读性,也可以使用块来逐行列出所有字段。
由于此指令是反向代理上带有预设行为的包装器,你可以使用reverse_proxy的任何子指令来自定义它。
扩展形式
forward_auth指令等同于以下配置。像Authelia这样的认证网关适合这个预设。如果你的网关不适合,可以借用下面的配置并按需自定义,而不是使用forward_auth快捷方式。
reverse_proxy <upstreams...> { # 始终使用 GET,避免消耗传入请求的 # 请求体 method GET # 将 URI 改为认证网关的 # 验证端点 rewrite <to> # 转发原始方法和 URI, # 因为它们会在上面被重写;这 # 是对 reverse_proxy 已设置的其他 # X-Forwarded-* 头的补充 header_up X-Forwarded-Method {method} header_up X-Forwarded-Uri {uri} # 成功响应时,复制响应头 @good status 2xx handle_response @good { # 例如,对每个 copy_headers 字段…… request_header Remote-User {rp.header.Remote-User} request_header Remote-Email {rp.header.Remote-Email} } }
示例
Authelia
在通过反向代理提供你的应用之前,将认证委托给Authelia:
# 提供认证网关本身 auth.example.com { reverse_proxy authelia:9091 } # 提供你的应用 app1.example.com { forward_auth authelia:9091 { uri /api/authz/forward-auth copy_headers Remote-User Remote-Groups Remote-Name Remote-Email } reverse_proxy app1:8080 }
更多信息,请参阅Authelia文档中与Caddy集成的说明。
Tailscale
将认证委托给Tailscale(目前名为nginx-auth,但它仍可与Caddy一起使用),并使用copy_headers的替代语法来重命名复制的头(注意每个头中的>):
forward_auth unix//run/tailscale.nginx-auth.sock { uri /auth header_up Remote-Addr {remote_host} header_up Remote-Port {remote_port} header_up Original-URI {uri} copy_headers { Tailscale-User>X-Webauth-User Tailscale-Name>X-Webauth-Name Tailscale-Login>X-Webauth-Login Tailscale-Tailnet>X-Webauth-Tailnet Tailscale-Profile-Picture>X-Webauth-Profile-Picture } }