lhumina_code/hero_os_tfgrid_deployer
0
0
Fork 0
Code Issues 13 Pull requests Projects Releases 2 Packages Wiki Activity Actions

Admin create-user success panel still tells tester to paste a Forge token #14

New issue
Closed
opened 2026-05-27 15:14:28 +00:00 by mik-tf · 1 comment
mik-tf commented 2026-05-27 15:14:28 +00:00
Owner
Copy link

After deployer.create_user succeeds, the green "User created" panel shows a "Next steps for the user" list:

  1. Log in at forge.ourworld.tf with the initial password.
  2. Open Settings > Applications and generate a new access token. Scope it to write:user.
  3. Paste the generated token into the cockpit's Settings page. The cockpit stores it under cockpit/USER_FORGE_TOKEN and uses it for all per-user Forge calls (SSH key upload, repo create, etc).
  4. Upload your SSH public key once via the cockpit, then proceed to Provision your VM.

That is the pre-SSO BYO-token flow (D-22, s160 BYO landing). With home#237 closed (Forge SSO + OAuth token persistence in hero_proxy), the new tester onboarding is meant to be SSO-first: the tester signs in to cockpit via Forge OAuth, grants consent once, and the per-user OAuth tokens are kept by hero_proxy under cockpit/USER_FORGE_OAUTH_* keyed by external_id hash. SSH key upload should be a one-time "log into forge.ourworld.tf and add a key under Settings > SSH Keys" step before provisioning, not a token-paste dance into cockpit.

Surface: crates/hero_tfgrid_deployer_admin/templates/users.html "user-created" panel "Next steps" list.

Update the copy to reflect the SSO-first flow:

  1. Log in at forge.ourworld.tf with the initial password and change it when prompted.
  2. Add your SSH public key under Settings > SSH Keys before asking the operator to provision a VM.
  3. Visit the tester cockpit URL the operator sent you, sign in with Forge, and grant consent once.

The paste-token path is still valid as a fallback for headless/scripted users (L-10) but is no longer the recommended onboarding for browser users.

After `deployer.create_user` succeeds, the green "User created" panel shows a "Next steps for the user" list: 1. Log in at forge.ourworld.tf with the initial password. 2. Open Settings > Applications and generate a new access token. Scope it to `write:user`. 3. Paste the generated token into the cockpit's Settings page. The cockpit stores it under `cockpit/USER_FORGE_TOKEN` and uses it for all per-user Forge calls (SSH key upload, repo create, etc). 4. Upload your SSH public key once via the cockpit, then proceed to Provision your VM. That is the pre-SSO BYO-token flow (D-22, s160 BYO landing). With home#237 closed (Forge SSO + OAuth token persistence in hero_proxy), the new tester onboarding is meant to be SSO-first: the tester signs in to cockpit via Forge OAuth, grants consent once, and the per-user OAuth tokens are kept by hero_proxy under `cockpit/USER_FORGE_OAUTH_*` keyed by external_id hash. SSH key upload should be a one-time "log into forge.ourworld.tf and add a key under Settings > SSH Keys" step before provisioning, not a token-paste dance into cockpit. Surface: `crates/hero_tfgrid_deployer_admin/templates/users.html` "user-created" panel "Next steps" list. Update the copy to reflect the SSO-first flow: 1. Log in at forge.ourworld.tf with the initial password and change it when prompted. 2. Add your SSH public key under Settings > SSH Keys before asking the operator to provision a VM. 3. Visit the tester cockpit URL the operator sent you, sign in with Forge, and grant consent once. The paste-token path is still valid as a fallback for headless/scripted users (L-10) but is no longer the recommended onboarding for browser users.
mik-tf commented 2026-05-27 15:50:05 +00:00
Author
Owner
Copy link

Fixed by squash-merge c649d76 on development. deployer.create_user next_steps now describes the SSO-first walk; paste-token path is kept as a documented fallback. Live verification queued for s170 redeploy.

Fixed by squash-merge `c649d76` on `development`. `deployer.create_user` next_steps now describes the SSO-first walk; paste-token path is kept as a documented fallback. Live verification queued for s170 redeploy.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
development
integration
latest
dev
Labels
Clear labels
No items
No labels
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
lhumina_code/hero_os_tfgrid_deployer#14
No description provided.