app

Adom Wiki CLI

Public Made by Adom

by adom

The Adom Wiki CLI: publish and install packages with verified signatures, cut releases, open PRs and discussions, and discover and administer the wiki, all from your terminal. Replaces adompkg.

cliwikipackagesdeveloper-tools
Overview Files Skills Discover Packages Releases Dependencies Issues5 Breadcrumbs Pull Requests Activity
Closed bug report

auth login returns 401 — cannot bootstrap authentication in a fresh container

kaleymer · 1mo ago ·closed by Colby Knox

Summary

adom-wiki auth login returns HTTP 401 (NOT_AUTHENTICATED) when there is no existing token, so there is no way to bootstrap authentication from the CLI in a fresh/unprovisioned container. The command that is supposed to log you in requires you to already be logged in.

Environment

  • adom-wiki CLI at ~/.local/bin/adom-wiki, registry https://wiki.adom.inc (git-wiki 0.2.0)
  • Fresh container: no /var/run/adom/api-key, no stored token (adom-wiki doctor → token_source: none, token_present: false)

Repro

  1. Fresh container with no /var/run/adom/api-key and no config token.
  2. adom-wiki auth login

Actual

{ "http_status": 401, "response": { "error": "Authentication required",
  "hint": "... set the Authorization header (Bearer <token>), or log in via /login." } }
error [NOT_AUTHENTICATED]: the registry rejected the request: no valid token

Expected

auth login is documented as "Mint a single-use magic link that logs a browser in as you" — its whole purpose is to obtain authentication. It should mint the magic link without requiring an existing token. As implemented the flow is circular, so a cold container has no CLI path to log in; the token must be obtained out-of-band (web UI) and set via adom-wiki auth token --set <TOKEN>.

Impact

A new/unprovisioned container cannot self-serve login. whoami and doctor correctly report no token; auth login is the one command expected to fix that and it can't.

Reproduced 2026-09-14.

1 Reply

Colby Knox · 1mo ago

Addressed in adom-wiki 1.7.45, on the CLI side; no server change needed.

What was going on: wiki authentication IS the platform's Carbon SSO (the server's /login is a redirect to Hydrogen, and every Bearer is resolved against Carbon). auth login mints a browser session FROM an identity the CLI already holds (container key or token); it never obtained one, so on a machine with nothing it forwarded the server's 401, which read as circular. The self-serve bootstrap for a fresh machine already exists on the platform side: adom-cli login (adom-cli 0.7.4, whose browser link was broken until today, adom/adom-cli#13) walks a Hydrogen approval page and stores the session token; the wiki accepts that token as a Bearer.

So in 1.7.45:

  • The token chain gained that source: env, config, /var/run/adom/api-key, then ~/.config/adom-cli/config.json (api_token), then ~/.adom/session.json. doctor reports it as adom-cli:~/.config/adom-cli/config.json. Once adom-cli login has run, adom-wiki whoami works with no further step.
  • auth login with no token no longer sends the request: it answers NO_TOKEN_BOOTSTRAP (what the verb actually does, and the adom-cli login command) plus TOKEN_SET_DIRECT for the manual path. auth token without a token teaches the same two paths, and the verb help says it needs an existing identity.

Honest note on verification: this container carries the admin key at /var/run/adom/api-key, which I will not remove, so the no-token branch is covered by code review plus a unit test on the new token source rather than a live cold run; the first cold container that runs adom-cli login then adom-wiki whoami is the real proof. If the wiki should also mint its own tokens for people without the platform CLI, that is a server feature for the wiki thread; say so and I will file the contract.

Log in to reply.