Skip to content

Restore the token-target fix onto develop - #34

Merged
wayneeseguin merged 4 commits into
developfrom
restore-token-target-fix
Jul 29, 2026
Merged

Restore the token-target fix onto develop#34
wayneeseguin merged 4 commits into
developfrom
restore-token-target-fix

Conversation

@wayneeseguin

Copy link
Copy Markdown
Contributor

Restores the content of #32, which merged but never reached develop.

#32 was opened against target-flag-selects-vault because it was stacked on
#31. #31 merged into develop first, so by the time #32 merged, its base
branch was already merged and discarded — the four commits landed on a branch
nothing reads. GitHub reports #32 as merged, and git merge-base --is-ancestor 0211147 origin/develop says no.

This is the same accident that lost #29 and needed #30 to recover.

The four commits are cherry-picked unchanged; the only difference between this
branch and target-flag-selects-vault is the README, which develop gained
from #30 and the stale branch never had. make check and go test -race ./...
are green.

What the commits fix

Config.SetToken only reaches the current target, and rc.Apply does not move
the current target — so with -T (or $SAFE_TARGET), every command that stores
a token wrote it against the wrong ~/.saferc entry.

  • safe -T beta logout printed "Successfully logged out of beta", left beta's
    token live in the file, and cleared alpha's instead. Verified against two live
    dev Vaults.

  • safe -T beta init stores the new root token against the current target,
    leaving the Vault it just initialized with no recorded token.

  • safe -T beta auth ... already worked, via a hand-rolled save-and-restore of
    Current around SetToken. That dance is what pointed at the defect in the
    first place; it collapses into the new call.

New rc.SetTokenFor(alias, token) names its target without touching Current
— which matters because Config.Write() persists Current, so any in-memory
switch would outlive the command that -T was supposed to scope. SetToken
now delegates to it. Two silently dropped errors on the auth path now surface.

Tests cover logout against a named target, logout with nothing targeted, auth
storing against a named target, and init storing the root token against a named
target, plus the rc unit test for SetTokenFor.

SetToken reaches only the current target, so a command told to act
on another one with -T had to move the current target aside and
put it back, and Write persists whatever it finds in between.
logout cleared the token of the current target and then reported
that it had logged out of the one -T named, so it left that Vault
logged in and signed the user out of another. A logout with no
target selected at all reported success too, having dropped the
error that says so.
auth reached the target -T named by making it current, setting the
token, and switching back, which is what SetTokenFor now does
without the detour. It also dropped the error from setting the
token, so a target that had gone missing looked like a success.
init put the root token of the Vault it had just initialized onto
the current target, leaving the initialized one with no token at
all, and read its Strongbox flag from the current target too.
@wayneeseguin
wayneeseguin merged commit 0391647 into develop Jul 29, 2026
@wayneeseguin
wayneeseguin deleted the restore-token-target-fix branch July 29, 2026 16:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant