Grey.ooo/someones.computer_agent
Watch
2
0
Fork
You've already forked someones.computer_agent
 0
Code Issues 2 Pull requests 1 Projects Releases 3 Packages Wiki Activity Actions

Add soc login: prompt for a token and link to the page that mints one #4

Merged
geusebio merged 2 commits from feature/login-token-prompt into main 2026-07-29 13:45:21 +00:00
Conversation 0 Commits 2 Files changed 9 +524 -11
geusebio commented 2026-07-29 12:27:13 +00:00
Owner
Copy link

Before this, an unconfigured soc deploy failed with "pass --token or set
$SOC_TOKEN" and left the user to work out where a token even comes from. Now
the CLI tells them, links them to the page, and stores what they paste.

What it does

soc login prints the platform's Settings → API tokens page for the current
endpoint, offers to open it in a browser, and reads the pasted token without
echoing it (x/term when stdin is a terminal; a piped stdin still works for
non-interactive use). A deploy with no token configured runs the same prompt
inline instead of failing.

Token resolution order:

Source Use
--token one-off override
$SOC_TOKEN CI
soc login store interactive machines

Tokens are stored per endpoint in credentials.json — $SOC_CONFIG_HOME,
else $XDG_CONFIG_HOME/soc, else ~/.config/soc — mode 0600 in a 0700
directory, written via temp-file + rename so an interrupted save can't truncate
it. Per-endpoint keying means a local stack and the hosted platform don't
overwrite each other; keys are normalised for trailing slash and case.

Verified against a real stack

Fresh config directory, no $SOC_TOKEN, deploying:

Application:  demo-app
  build web              .  sha256:1c38e264b87b  (199 B)

No API token configured for http://127.0.0.1:7714

Create an API token at:

    http://127.0.0.1:7714/settings/api-tokens

Paste your token:
Token saved for http://127.0.0.1:7714 (/tmp/soc-full-75069/credentials.json)

Deployment 019fadd6-8ff4-726a-805d-387fbc18e8db created — seq 3, status pending

That ran against the platform's docker stack with both server-side branches
merged locally, so the whole path — prompt → store → authenticated upload → a
pending Deployment attributed to the token's user — is proven, not just the
prompt.

go vet ./... and go test ./... pass; new coverage for the config store
(round-trip, 0600 mode, per-endpoint keying, corrupt file) and for login
(prints the URL, stores what's pasted, rejects an empty token, resolution
precedence).

Depends on

  • Platform PR Someones.Computer#66
    adds /settings/api-tokens — the page this links to. Merge that first, or the
    link 404s.
  • Platform PR Someones.Computer#64
    adds the bundle-ingest endpoint the deploy above posts to.

Notes

  • go.mod picks up golang.org/x/term (pinned to v0.27.0 deliberately: the
    current release requires Go 1.25, and CI pins 1.24).
  • The OS keychain (go-keyring) is still the intended upgrade; this file store
    is the documented fallback and stays as the fallback when that lands.
  • No token validation on login — there's no whoami endpoint yet, so a typo
    surfaces on the next deploy as a 401.
Before this, an unconfigured `soc deploy` failed with *"pass `--token` or set `$SOC_TOKEN`"* and left the user to work out where a token even comes from. Now the CLI tells them, links them to the page, and stores what they paste. ## What it does `soc login` prints the platform's **Settings → API tokens** page for the current endpoint, offers to open it in a browser, and reads the pasted token **without echoing it** (`x/term` when stdin is a terminal; a piped stdin still works for non-interactive use). A `deploy` with no token configured runs the same prompt inline instead of failing. Token resolution order: | Source | Use | | --- | --- | | `--token` | one-off override | | `$SOC_TOKEN` | CI | | `soc login` store | interactive machines | Tokens are stored **per endpoint** in `credentials.json` — `$SOC_CONFIG_HOME`, else `$XDG_CONFIG_HOME/soc`, else `~/.config/soc` — mode `0600` in a `0700` directory, written via temp-file + rename so an interrupted save can't truncate it. Per-endpoint keying means a local stack and the hosted platform don't overwrite each other; keys are normalised for trailing slash and case. ## Verified against a real stack Fresh config directory, no `$SOC_TOKEN`, deploying: ``` Application: demo-app build web . sha256:1c38e264b87b (199 B) No API token configured for http://127.0.0.1:7714 Create an API token at: http://127.0.0.1:7714/settings/api-tokens Paste your token: Token saved for http://127.0.0.1:7714 (/tmp/soc-full-75069/credentials.json) Deployment 019fadd6-8ff4-726a-805d-387fbc18e8db created — seq 3, status pending ``` That ran against the platform's docker stack with both server-side branches merged locally, so the whole path — prompt → store → authenticated upload → a `pending` Deployment attributed to the token's user — is proven, not just the prompt. `go vet ./...` and `go test ./...` pass; new coverage for the config store (round-trip, `0600` mode, per-endpoint keying, corrupt file) and for `login` (prints the URL, stores what's pasted, rejects an empty token, resolution precedence). ## Depends on - Platform PR [Someones.Computer#66](https://git.grey.ooo/Grey.ooo/Someones.Computer/pulls/66) adds `/settings/api-tokens` — the page this links to. Merge that first, or the link 404s. - Platform PR [Someones.Computer#64](https://git.grey.ooo/Grey.ooo/Someones.Computer/pulls/64) adds the bundle-ingest endpoint the deploy above posts to. ## Notes - `go.mod` picks up `golang.org/x/term` (pinned to v0.27.0 deliberately: the current release requires Go 1.25, and CI pins 1.24). - The OS keychain (`go-keyring`) is still the intended upgrade; this file store is the documented fallback and stays as the fallback when that lands. - No token validation on `login` — there's no whoami endpoint yet, so a typo surfaces on the next deploy as a 401.
Add soc login: prompt for a token and link to the page that mints one
All checks were successful
CI / build (pull_request) Successful in 5m3s
Details
68a425916c
 
Before this, an unconfigured `soc deploy` failed with "pass --token or set
$SOC_TOKEN" and left the user to work out where a token comes from. Now the CLI
prints the platform's Settings → API tokens page for the current endpoint,
offers to open it in a browser, and reads the pasted token without echoing it.
A `deploy` with no token runs the same prompt inline rather than failing.

Tokens are stored per endpoint in credentials.json (0600, in a 0700 directory,
written via a temp file + rename), so a local stack and the hosted platform can
each have their own without overwriting. Resolution order is --token, then
$SOC_TOKEN (what CI sets), then the store.

Reading the pasted value goes through x/term when stdin is a terminal, so the
token never lands in a scrollback buffer; a piped stdin still works for
non-interactive use.
Merge main into the login branch, adopting the sc rename
All checks were successful
CI / build (pull_request) Successful in 4m32s
Details
48906aec39
 
main renamed the binary soc -> sc and the SOC_* env vars to SC_* after this
branch was cut, which collided with every part of the login work. Resolved in
favour of the new naming throughout: $SC_TOKEN, the `sc login` usage text, and
the credential store's own SC_CONFIG_HOME / ~/.config/sc/credentials.json.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
⏳in-progress
Someone is actively working this right now — do not start a second pass on it

No labels
⏳in-progress
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Grey.ooo/someones.computer_agent!4
No description provided.