Repository navigation
Conversation
When external IP discovery fails, the psql view skips its IP allow-list check and goes on to build the child command from the database's external connection string. If that string is nil or empty, `psql -c` (and the interactive psql/pgcli path) is started with no connection target, so libpq falls back to its local or PG* environment defaults - SQL meant for the selected Render database can be sent somewhere else. Resolve the external connection string through getExternalConnectionString, which returns an error naming the database when the value is nil, empty or whitespace-only, before either child is built. The guard holds whether IP discovery succeeded or failed, so the existing fallback still works for real targets. getUserIP becomes a package variable so tests can fake discovery.
puncsky
added a commit
to bex-co/bex
that referenced
this pull request
Oct 10, 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
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
When external IP discovery fails (for example api.ipify.org is unreachable), the psql view skips the IP allow-list check and builds the child command from the database's external connection string. If that string is nil or empty,
render psql <db> -c "..."(and the interactive psql/pgcli path) starts the client with no connection target, so libpq falls back to its local socket orPG*environment defaults. SQL intended for the selected Render database can then run against whatever those defaults point to.This adds
getExternalConnectionString, which returns an error naming the database when the external target is nil, empty or whitespace-only, before either child command is built. The guard applies whether IP discovery succeeded or failed, so the existing "continue without the IP check" fallback still works for databases that do have an external target.getUserIPbecomes a package variable so tests can fake discovery.Motivation
Found while testing the CLI against a Render-compatible API: a private database (no external connection string) plus an IP-discovery failure launched
psqlwith an empty target. No wrong-database query was observed, but the empty target makes one possible wheneverPGHOST/PGDATABASEor a local server are present.How to verify
go test ./pkg/tui/views/...— newpsql_test.gocovers nil, empty and whitespace targets (refused, naming the database) for both-cand interactive tools, with IP discovery both failing and succeeding, plus the valid-target path.TrimSpacefails exactly the whitespace cases.go test ./...passes excepte2e/TestE2E, which fails identically onmainwithout credentials (rate limited).Release notes