fix: validate X-Umami-Host with actionable errors (refs #29) - #31
Merged
Conversation
When the host lacks a scheme or is the literal string `**********`, return a clear JSON-RPC error explaining the problem instead of a cryptic Go `net/url` parse error. The `**********` case specifically catches OpenHands' redacted-secret placeholder leaking into outbound MCP requests (refs #29).
Closed
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.
Summary
X-Umami-Host(and the stdio-config equivalent) at the top ofAuthenticate(). If it's missing anhttp:///https://scheme, return a clear message naming the offending value. If it's the literal string**********, return a message that specifically points at MCP-client secret-redaction placeholders (e.g. OpenHands) leaking into the outbound request.net/urlparse error (first path segment in URL cannot contain colon) is replaced with something actionable.Context
Follow-up to #29 (OpenHands 1.12.0 fails to initialize the server). Root cause on the client side is a combination of: (a) OpenHands' MCP settings form parsing headers as
KEY=VALUE(equals-separated, notKey: value), which silently discards HTTP-style entries; and (b) a known family of bugs (see OpenHands PR #16144, SDK issue #4096, SDK PR #4097) where the redacted-secret placeholder**********leaks back into outbound requests after an edit/save cycle. Either failure mode produced an opaque parse error on our side; this PR makes both diagnosable.Test plan
go test ./...passes locallygo run github.com/golangci/golangci-lint/cmd/golangci-lint@v1.64.8 run ./...clean