希望添加 APIKEY / 用户级别 IP 白名单功能

[oubeichen]

目前cch，若部署在公网云服务器上，不免会有暴露风险。
假设有供某个不安全的服务用的使用需求，不在一个内网。与此同时，此cch还有其他客户端（非固定IP）的使用需求，则不方便直接给机器加防火墙。只能依赖服务内根据用户、APIKEY级别来提供黑白名单功能。
因此希望能有 APIKEY 或者用户级别的 IP 白名单，就算拿到了 API KEY也无法调用，防止滥用。

[github-actions]

Thank you for this feature suggestion. This is a valid security enhancement request - IP whitelisting at the API Key or User level would provide defense-in-depth against API key leakage.

Feasibility assessment:

Based on codebase analysis, this feature is architecturally feasible. The proxy pipeline already has the necessary infrastructure for IP-based checks.

Related existing code:

1. IP extraction logic - src/app/v1/_lib/proxy/auth-guard.ts (lines 23-39)

   • Already extracts client IP from x-real-ip and x-forwarded-for headers
   • Used for pre-auth rate limiting

2. Guard pipeline architecture - src/app/v1/_lib/proxy/guard-pipeline.ts (lines 1-210)

   • Configurable chain of guards (auth, client, model, rateLimit, etc.)
   • New guards can be added by implementing GuardStep interface

3. Database schema - src/drizzle/schema.ts

   • Users table (lines 38-97): Already has allowedClients and allowedModels arrays
   • Keys table (lines 100-140): Similar restriction patterns could be applied

4. API key validation - src/repository/key.ts (lines 512-691)

   • validateApiKeyAndGetUser function handles authentication and returns user/key info

Implementation considerations:

1. Schema changes: Add allowedIps (string array) field to keys and/or users table, similar to existing allowedClients/allowedModels pattern

2. New guard step: Add an ipWhitelist guard after auth in the pipeline (see CHAT_PIPELINE config at line 186)

3. IP matching logic: Support both single IPs and CIDR ranges (e.g., 192.168.1.0/24) for flexibility

4. IPv6 support: Should handle both IPv4 and IPv6 addresses

5. UI changes: Dashboard would need form fields for managing IP whitelists per key/user

6. i18n: New UI strings would need translation (5 languages per CLAUDE.md requirements)

Dependencies:

• Database migration (via bun run db:generate)
• Redis cache updates for API key auth results
• Dashboard UI forms for key/user management

Existing similar pattern:

The allowedClients and allowedModels fields in the users table (schema.ts lines 69-78) provide a direct template for how IP whitelists could be implemented and validated.

---

Automated response from Claude AI

[miraserver]

我可能会实现这个，但稍晚一点。请把这项任务分配给我