2作者: dayt0n6 个月前
我目前正在进行一个大型项目,该项目需要一个基于单独的带外身份验证流程的短效 HTTP "auth"。由于每个允许的 IP 只需要在特定服务器名称上被允许几分钟,所以我创建了这个项目来解决这个问题。它应该与任何兼容 Redis 的数据库一起使用。对于 docker-compose 示例,我使用了 valkey。 这主要在你想要控制对多个域的访问时有用。如果你想允许 1.1.1.1 访问 mywebsite.com 和 securesite.com,以及 2.2.2.2 访问 securesite.com 和 anothersite.org,并设置一定的 TTL,你只需要在你的 Redis 兼容数据库中设置哈希键,如下所示: 1.1.1.1: ``` - mywebsite.com: 1 (30 秒 TTL) - securesite.com: 1 (15 秒 TTL) ``` 2.2.2.2: ``` - securesite.com: 1 (3600 秒 TTL) - anothersite.org: 1 (永不过期) ``` 由于你可以使用任何兼容 Redis 的数据库作为后端,因此鼓励使用每个条目的 TTL。 也可以使用进程内缓存,但除非你向 kvauth 传递 --enable-l1-cache,否则不会启用。这使得成功的 auth_requests 速度更快,因为程序不必在每次请求时都访问键/值数据库。 我没有对此进行任何硬核的性能分析,但启用了 chi 日志中间件,以查看请求通常需要多长时间: kvauth-1 | 2025/12/30 21:32:28 "GET http://127.0.0.1:8888/kvauth HTTP/1.0" 来自 127.0.0.1:42038 - 401 0B,耗时 300.462µs # 不允许的请求 nginx-1 | 192.168.65.1 - - [30/Dec/2025:21:32:28 +0000] "GET / HTTP/1.1" 401 179 "-" "curl/8.7.1" kvauth-1 | 2025/12/30 21:32:37 "GET http://127.0.0.1:8888/kvauth HTTP/1.0" 来自 127.0.0.1:40160 - 401 0B,耗时 226.189µs # 不允许的请求 nginx-1 | 192.168.65.1 - - [30/Dec/2025:21:32:37 +0000] "GET / HTTP/1.1" 401 179 "-" "curl/8.7.1" # IP 添加到 redis 允许列表 kvauth-1 | 2025/12/30 21:34:02 "GET http://127.0.0.1:8888/kvauth HTTP/1.0" 来自 127.0.0.1:54032 - 200 0B,耗时 290.648µs # 允许,但必须访问 valkey kvauth-1 | 2025/12/30 21:34:02 "GET http://127.0.0.1:8888/kvauth HTTP/1.0" 来自 127.0.0.1:54044 - 200 0B,耗时 4.041µs nginx-1 | 192.168.65.1 - - [30/Dec/2025:21:34:02 +0000] "GET / HTTP/1.1" 200 111 "-" "curl/8.7.1" kvauth-1 | 2025/12/30 21:34:06 "GET http://127.0.0.1:8888/kvauth HTTP/1.0" 来自 127.0.0.1:51494 - 200 0B,耗时 6.617µs # 允许,使用了缓存 kvauth-1 | 2025/12/30 21:34:06 "GET http://127.0.0.1:8888/kvauth HTTP/1.0" 来自 127.0.0.1:51496 - 200 0B,耗时 3.313µs nginx-1 | 192.168.65.1 - - [30/Dec/2025:21:34:06 +0000] "GET / HTTP/1.1" 200 111 "-" "curl/8.7.1" IP 允许列表不是真正的身份验证,任何此项目的生产实现都应该将其仅用作身份验证流程的一部分。这旨在解决 NGINX 的动态 IP 允许列表的特定问题。