Repository navigation
Restrict deployment redirects and credential headers - #389
Merged
Merged
Conversation
Toolbox can show the connection step more than once during startup. A second CLI login could fail after the first succeeded and send the user back to token entry. The wizard now starts one connection attempt at a time. A retry waits for the cancelled attempt to finish, and only the active attempt can publish a session or report a failure. Saved sessions restore behind the workspace list. If restoration fails, the wizard opens the sign-in form so the user can reconnect.
A workspace link for another deployment could leave the previous setup page visible until Toolbox regained focus. The provider now displays the replacement wizard as soon as it handles the link, so setup can continue while Toolbox stays in focus.
The HTTP clients follow redirects automatically, and the CLI downloader attaches deployment headers to configured mirrors. A request can therefore carry credentials outside the intended origin. Toolbox follows same-origin redirects for reads and scopes authentication headers to the deployment. For CLI versions that support redirect control, Toolbox disables redirects for authenticated commands and generated SSH connections.
An OAuth credential update can fail after the provider accepts the session. Treating that error as a failed sign-in sends the user back to setup even though the workspace connection is active. The wizard now logs the error and keeps the signed-in session open. A regression test covers a credential store that rejects the update.
Setup logs the CLI in with the current OAuth token. Calling the token refresh handler again after sign-in repeats that login and can leave the CLI and the saved session out of sync. The wizard now saves the OAuth session directly after setup. The refresh handler still updates credentials when a running session receives a new token. A test checks the login count and saved token.
The provider tests use short deployment names and repeat the setup for several credential choices. This makes it hard to see which deployment receives a link and which credentials the wizard should use. The tests name the source and target deployments and cover the restore choices in a table. Their assertions identify when the CLI signs in and which workspace page the provider opens.
Setup assumes a token exists when it hands credentials to the CLI. If the user switches from certificate to token authentication during setup, a missing token can produce an error with no explanation. The HTTP client and CLI now use the same token check. The wizard reports a missing token and skips CLI login for certificate sessions. Tests cover both paths.
Looking up a page to display can start a CLI sign-in. The wizard also uses a separate step and a flag to track how the connection started. The router now starts a saved-session restore when it registers the wizard. Looking up the page only selects what Toolbox displays. The wizard records the origin of the connection so a failed restore can show the sign-in form and repeated callbacks reuse the active job.
The redirects branch predates the latest sign-in fixes. It carries an older setup wizard and a separate change to the HTTP client. The merge brings in the reviewed wizard changes and preserves the redirect restrictions. Session restore uses the updated sign-in flow when the HTTP client connects to a deployment.
The interceptor lists six HTTP status codes, duplicating the redirect check that OkHttp already provides. It now uses response.isRedirect to recognize those same six codes.
The redirect loop uses a literal limit, which makes its policy hard to see. The interceptor now names the limit and explains why it follows same-origin GET and HEAD requests and allows up to 20 redirects. A test covers the last allowed redirect and the first refused one. The two CLI tests changed by the redirects branch now select their workspace agents without forcing nullable lists to be present.
Main contains the setup wizard fixes from PR #388 as a squash commit. The redirects branch already includes those fixes through its original parent. The merge keeps the shared session token check and scopes the authentication header to the configured deployment.
The setup wizard stored the sign-in origin separately from its current step. After a failed restore, the wizard had to reset the origin before the user could try again from the form. The connecting step now holds the origin. Returning to a form or completing sign-in drops it automatically. The provider tests check which origin the wizard uses for saved sessions and workspace links.
jeremyruppel
approved these changes
Nov 13, 2026
The origin helper accepted only Java URLs, so both header interceptors repeated the origin comparison for OkHttp requests. The helper now accepts an OkHttp request URL. Both interceptors use it to add deployment headers only when the request and deployment have the same scheme, host, and effective port.
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.
The HTTP clients follow redirects automatically, and the CLI downloader attaches deployment headers to configured mirrors. A request can therefore carry credentials outside the intended origin.
Toolbox follows same-origin redirects for reads and scopes authentication headers to the deployment. For CLI versions that support redirect control, Toolbox disables redirects for authenticated commands and generated SSH connections.