Check the address a supervisor hands back before calling it - #51
Merged
Conversation
`resolveBaseUrl` returns a URL and the next line puts it into `fetch` with this deployment's computer token on it. That was fine while the only supervisor was ours, answering on loopback. It stops being fine with a hosted provider, where the address arrives from a third party's API and we call whatever it says. Deliberately not the navigation check. That one refuses private hosts, which is correct for a Bot browsing and exactly wrong here: our own supervisor answers `http://127.0.0.1:<port>` for a container on this machine, so reusing it would refuse the ordinary case. What survives is what holds however the address was produced. The scheme has to be one a computer speaks, and the cloud metadata addresses are refused whatever anything says, because that is how a container's credentials leave it and no supervisor has a reason to name one. Groundwork for A10, where the supervisor becomes somebody else's API.
davidmckayv
requested review from
MikeRyanDev,
guidovizoso and
tylerslaton
as code owners
August 20, 2026 17:45
guidovizoso
approved these changes
Aug 20, 2026
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
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.
Groundwork for A10, where the supervisor stops being ours.
The gap
resolveBaseUrlreturns a URL and the next line puts it straight intofetch, carrying this deployment'sCOMPUTER_TOKEN:No validation between the two. That has been fine because the only supervisor is ours, answering on loopback. It stops being fine the moment the address comes from a hosted provider's API, because then we call whatever a third party returns, with a credential attached.
Not the navigation check
checkNavigationTargetalready exists and is the wrong tool. It refuses private hosts, which is right for a Bot browsing and precisely wrong here: our own supervisor answershttp://127.0.0.1:<port>for a container on this machine, so reusing it would refuse the normal case on every deployment we have.checkComputerAddresskeeps only what holds however the address was produced:httporhttpsPrivate addresses stay allowed, deliberately, and the comment says why so nobody "fixes" it later.
Tests
Five cases, including the two that matter for the shape of this: the loopback address our own supervisor returns is allowed, and a
169.254.169.254address is refused however it arrived. 21 pass in that file.Where it runs
Boundary and audit
ComputerUnavailableError, the same way an unreachable computer already does, so the operator gets a sentence rather than a stack trace.Proof
Server restarted on this branch,
/api/computers/supervisor/computersstill lists computers through the real supervisor, so the loopback path is unaffected.format:check,lint,typecheckclean. 692 pass, 5 skip, 0 fail.