You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fall back to file cache on read when keyring is unreachable
Mirrors the login-path fallback for the read path. When the resolver
returns (mode=Secure, source=Default) and the keyring probes as
definitively unreachable, ResolveCache now returns the file cache
instead of the keyring. This means users upgrading on systems without
a usable keyring (e.g. Linux containers without a D-Bus session bus)
keep reading from their pre-upgrade token-cache.json without any
manual configuration.
Two behaviours intentionally differ from the login-path fallback:
1. The probe is read-only (ProbeKeyringRead does a Get on a non-existent
account name, treating keyring.ErrNotFound as "reachable"). The
login-path probe still uses the write+delete cycle because login
needs to validate write capability before committing tokens.
2. The read-path fallback does NOT persist auth_storage = plaintext to
[__settings__]. A read failure could be transient (e.g. a momentarily
broken D-Bus connection) and we don't have strong enough evidence to
pin the user out of the keyring permanently. Pinning stays the
responsibility of the login command, which has the stronger
write-probe signal and an explicit user action.
Timeouts in the read probe stay on the keyring (same logic as the login
path): a locked keyring being unlocked is the most common timeout case,
and a misdiagnosed hang fails the actual Lookup, which is preferable to
silently routing reads to a different backend.
Explicit-secure callers (env var or config) get the keyring cache
regardless of probe result, so an explicit "I want secure" request
surfaces the unreachability instead of being silently downgraded.
Co-authored-by: Isaac
Copy file name to clipboardExpand all lines: NEXT_CHANGELOG.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@
4
4
5
5
### Notable Changes
6
6
7
-
* Breaking change: OAuth tokens for interactive logins (`auth_type = databricks-cli`) are now stored in the OS-native secure store by default (Keychain on macOS, Credential Manager on Windows, Secret Service on Linux) instead of `~/.databricks/token-cache.json`. After upgrading, run `databricks auth login` once per profile to re-authenticate; cached tokens from older versions are not migrated. To keep the previous file-backed storage, set `DATABRICKS_AUTH_STORAGE=plaintext` or add `auth_storage = plaintext` under `[__settings__]` in `~/.databrickscfg` (the env var takes precedence over the config setting), then re-run `databricks auth login`.
7
+
* Breaking change: OAuth tokens for interactive logins (`auth_type = databricks-cli`) are now stored in the OS-native secure store by default (Keychain on macOS, Credential Manager on Windows, Secret Service on Linux) instead of `~/.databricks/token-cache.json`. After upgrading, run `databricks auth login` once per profile to re-authenticate; cached tokens from older versions are not migrated. To keep the previous file-backed storage, set `DATABRICKS_AUTH_STORAGE=plaintext` or add `auth_storage = plaintext` under `[__settings__]` in `~/.databrickscfg` (the env var takes precedence over the config setting), then re-run `databricks auth login`. On systems where the OS keyring is not reachable (e.g. Linux containers without a D-Bus session bus), the CLI transparently falls back to the file cache when reading tokens so legacy `token-cache.json` entries remain accessible without manual configuration.
0 commit comments