feat(serve): require an auth token by default (secure on shared login nodes)#97
Merged
Merged
Conversation
…skit/web-token Auto-generate and enforce a web access token even for 127.0.0.1 binds. On a shared host (e.g. an HPC login node) loopback is not isolated per user, so binding 127.0.0.1 alone does not keep other local users out — only the token does. Previously a token was generated only for non-localhost binds, leaving the common default wide open on shared login nodes. - Persist the token at ~/.harnesskit/web-token (mode 0600) and reuse it across restarts; a file with looser permissions is treated as compromised and regenerated. - Add --no-token to opt out on a trusted single-user machine. - Embed the token in the 127.0.0.1 startup URL, and store it in localStorage so one ?token= visit logs in and survives new tabs/reloads. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
hk servedefaulted to--host 127.0.0.1with no token — a token was auto-generated only for non-localhost binds. On a shared host (e.g. an HPC login node) the loopback interface is not isolated per user, so binding127.0.0.1does not keep other local users out. Any user on the same node couldss -ltn | grep 7070, thencurl 127.0.0.1:7070and reach the HarnessKit UI — including install / clone / toggle actions — with no auth.Change
Secure-by-default token, enforced even for
127.0.0.1:~/.harnesskit/web-token(mode0600), reused across restarts. A file with looser permissions is treated as compromised and regenerated.--token) so it never leaks throughps//proc/<pid>/cmdlineto other users on the host.--no-tokenopt-out for a trusted single-user machine.127.0.0.1startup URL and store it inlocalStorage, so one?token=visit logs in and survives new tabs/reloads (wassessionStorage).?token=URL and note it's saved for next time.The static frontend shell is still served unauthenticated (no secrets in it); all
/api/routes are token-gated, so other users get an empty, non-functional shell at most. Hiding the shell/port entirely (query-param auth on all routes, or a Unix-socket mode) is left as a follow-up.Testing
cargo test --workspace+npm testgreen. Added 3 unit tests for the token-file logic (round-trip + 0600, reject group/world-readable, re-harden on overwrite).x86_64-unknown-linux-musland tested on a real shared HPC login node: from a second session on the same node, unauthenticated/api/*returns 401;~/.harnesskit/web-tokenis-rw-------. Another user sees only the empty static shell.🤖 Generated with Claude Code