feat(auth): persist org_name and org_id from login/signup#199
Merged
Conversation
The login/signup API response includes both org_name and org_id. Prior to this change the CLI printed them in the success banner and discarded them. Now they're persisted to ~/.versrc as orgName and orgID, with a GetOrgName() helper that mirrors GetAPIKey's env-then-config precedence (VERS_ORG wins). A new SaveAuth(apiKey, orgName, orgID) helper performs a single write so the login path doesn't need to load+modify+save. Unblocks two follow-ups: - vers agent-context can surface the current org without an extra API call - vers repo get can synthesize <org>/<repo>:<tag> client-side, so users can see the canonical public reference for their own repos without consulting the public discovery endpoint Empty values passed to SaveAuth don't clobber persisted ones, so a key rotation via SaveAuth(newKey, "", "") preserves the previously-stored org identity. Tested: - internal/auth/auth_test.go gains TestGetOrgName with four sub-cases (no config, persist-and-read, env override, empty-doesn't-clobber) - all existing tests pass
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.
Why
When a user runs
vers loginorvers signup, the API response includes bothorg_nameandorg_id. The CLI prints them in the success banner and then discards them. That makes the canonical<org>/<repo>:<tag>reference unconstructable client-side, even though the server already told us the org name.Surfaced naturally while documenting how to share a public repo:
vers repo get pi-agentdoesn't say what orgpi-agentbelongs to, because the API'sRepositoryInforesponse doesn't include it (PublicRepositoryInfodoes, but that's a different endpoint). Without persisted org info, a user can't construct their own public reference without the upstream API including it on every endpoint.What
Configstruct gainsOrgNameandOrgIDfields (omitempty so existing~/.versrcfiles don't gain noisy keys).SaveAuth(apiKey, orgName, orgID)helper — single write, used by login. Empty values don't clobber persisted ones, so a future key-only rotation preserves org identity.GetOrgName()helper — mirrorsGetAPIKey:VERS_ORGenv wins, falls back to config.Doesn't include (deliberate follow-ups, not yet tracked)
org_nameinvers agent-context— a natural addition; this PR unblocks it but doesn't ship itvers repo getsynthesizing<org>/<repo>:<tag>client-sidevers whoamito introspect the persisted identityA follow-up issue should be filed for these. Issue #193 currently only covers the
feedbackandjobsblocks ofagent-context; org/identity surfacing is a separate concern.Tests
New
TestGetOrgNamewith 4 sub-cases:Covers: no config returns empty, persist-and-read,
VERS_ORGenv override, empty values toSaveAuthdon't clobber existing.All existing tests pass.
make build,gofmt,go vetclean.Backwards compatibility
Strictly additive. Existing
~/.versrcfiles withoutorgName/orgIDcontinue to work; the fields populate on next login/signup. No breaking change.