feat(server): add --allowed-host flag for DNS-rebinding allowlist - #1128
Conversation
- add `kimi server run --allowed-host <host...>` (repeatable or comma-separated; leading dot matches a domain suffix) and thread it through daemon spawn into startServer - merge CLI allowed hosts with KIMI_CODE_ALLOWED_HOSTS for both the HTTP and WebSocket Host checks - include the rejected host and allow guidance in the 403 error message
🦋 Changeset detectedLatest commit: 62389ee The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 62389eee15
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| .flatMap((entry) => entry.split(',')) | ||
| .map((entry) => entry.trim()) | ||
| .filter((entry) => entry.length > 0); |
There was a problem hiding this comment.
Normalize allowed host entries before forwarding
When a user passes the actual Host header value to the new --allowed-host flag, common values like app.example.com:58627 or mixed-case hosts are forwarded unchanged, but isAllowedHost() lowercases and strips the port only from the incoming request before comparing against extra. In that scenario the newly added flag still rejects the same host it was meant to allow, so the CLI parser should normalize entries the same way the request side is normalized.
Useful? React with 👍 / 👎.
…onshotAI#1128) - add `kimi server run --allowed-host <host...>` (repeatable or comma-separated; leading dot matches a domain suffix) and thread it through daemon spawn into startServer - merge CLI allowed hosts with KIMI_CODE_ALLOWED_HOSTS for both the HTTP and WebSocket Host checks - include the rejected host and allow guidance in the 403 error message (cherry picked from commit 0886bff)
Related Issue
No linked issue — problem explained below.
Problem
The server's DNS-rebinding Host check rejects any
Hostoutside the default allowlist with a bare403 Invalid Host header. Users who frontkimi serverwith a reverse proxy or reach it via a custom domain have two friction points:KIMI_CODE_ALLOWED_HOSTSenvironment variable.What changed
kimi server run --allowed-host <host...>flag. It is repeatable and comma-separated, and a leading dot matches a domain suffix (e.g.--allowed-host .example.com). The value is threaded throughparseServerOptions→spawnDaemonChild(for daemon mode) →startServerBackground→startServer.startServernow merges the CLI-provided hosts withKIMI_CODE_ALLOWED_HOSTS, so both sources feed the same allowlist for the HTTP and WebSocket Host checks.Invalid Host headermessage withformatHostErrorMessage(), which names the rejected host and prints the exact fix, e.g.allow this host with KIMI_CODE_ALLOWED_HOSTS=evil.com or 'kimi server run --allowed-host evil.com'.packages/server/SECURITY.mdto document the flag and added unit + e2e coverage for the flag parsing, daemon arg threading, and the new 403 message.Checklist
gen-changesetsskill, or this PR needs no changeset. (changeset included:.changeset/server-allowed-host-flag.md)gen-docsskill, or this PR needs no doc update. (packages/server/SECURITY.mdupdated inline to cover the flag.)