auth describe: try both verification endpoints before reporting failure#5512
Open
simonfaltum wants to merge 2 commits into
Open
auth describe: try both verification endpoints before reporting failure#5512simonfaltum wants to merge 2 commits into
simonfaltum wants to merge 2 commits into
Conversation
getAuthStatus made exactly one verification call based on the client type MustAnyClient picked (account client -> Workspaces.List, workspace client -> CurrentUser.Me) and reported "Unable to authenticate" when that call failed, even when the credentials were valid. Account console profiles that also carry a workspace_id resolve to a workspace client, and CurrentUser.Me always fails against the accounts host (#5479). If the first verification call fails, build the other client type from the same resolved config (non-interactively, over the same config pointer) and try its verification call before reporting failure. If both fail, report the first error. Success paths still make exactly one call. Co-authored-by: Isaac
A 403 response means the server authenticated the caller and refused the operation; invalid credentials produce a 401. When both verification endpoints fail but at least one failure is an HTTP 403 API error, report success instead of failure. This makes describe truthful for non-admin users on account hosts, where Workspaces.List is account-admin-only (returns 403) and the account console cannot serve CurrentUser.Me (returns 400), so both checks fail even though the credentials are perfectly valid. Username stays empty in this case; the output template omits it. Co-authored-by: Isaac
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
Contributor
Approval status: pending
|
Collaborator
|
Commit: 5d3fa86
24 interesting tests: 15 SKIP, 7 KNOWN, 2 flaky
Top 28 slowest tests (at least 2 minutes):
|
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
2 participants
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.
Why
databricks auth describemakes a single verification call based on the client type it resolved (workspace client:CurrentUser.Me, account client:Workspaces.List). If that one call fails, describe prints "Unable to authenticate" even when the credentials are perfectly valid. Two real cases hit this on account console profiles:account_idandworkspace_id(older logins wrote this shape) resolves to a workspace client. The token works, butCurrentUser.Meagainst the accounts host always fails with HTTP 400, so describe reports failure whiledatabricks auth tokensucceeds.Workspaces.Listis account-admin-only and returns HTTP 403, so describe reports failure even though the login is fine.Fixes #5479.
Changes
Before, describe gave up after one failed verification call; now it tries the other endpoint first and only reports failure when neither proves the credentials.
Commit 1: if the first verification call fails, describe builds the other client type from the same resolved config (non-interactively, over the same config pointer) and tries its verification call. Account branch falls back to
CurrentUser.Me; workspace branch falls back toWorkspaces.Listwhen anaccount_idis configured (account clients require one). If the fallback succeeds, describe reports success with the matching fields (username fromMe, account ID for account-side success). If both calls fail, describe reports the first error. Success paths still make exactly one call.Commit 2 (separable, easy to drop in review): if both checks fail but at least one failure is an API error with HTTP 403, describe reports success. A 403 means the server authenticated the caller and refused the operation; invalid credentials produce a 401, so a 403 proves the login works. This makes describe truthful for non-admin users on account hosts, where
Workspaces.Listreturns 403 and the console cannot serveMe(400). Username stays empty in that case and the output template omits it. The check useserrors.AsType[*apierr.APIError]and the status code, no string matching.The output templates are unchanged otherwise.
Test plan
cmd/auth/describe_test.go: workspace check fails then account check succeeds; account check fails then workspace check succeeds; both fail with non-403 errors reports the first error; no second call without anaccount_id; both fail with a 403 reports success (account branch, workspace fallback, and workspace branch without fallback)acceptance/cmd/auth/describe/account-host-with-workspace-id: end-to-end reproduction of the issue (workspace client on an account host,Mereturns 400, account fallback succeeds)acceptance/cmd/auth/describe/account-permission-denied: non-admin account profile, both checks fail (403 + 400), describe reports success./task fmt-q,./task lint-q,./task checksThis pull request and its description were written by Isaac.