lhumina_code/home
0
0
Fork 0
Code Issues 63 Pull requests Projects Releases Packages Wiki Activity Actions

Simplify tester onboarding: reuse existing Forge users, drop tester SSH keys, clearer access errors #247

New issue
Open
opened 2026-06-03 23:37:40 +00:00 by mik-tf · 2 comments
mik-tf commented 2026-06-03 23:37:40 +00:00
Owner
Copy link

Goal: make onboarding a tester as simple as possible for non-technical people. An admin adds a tester (new or existing Forge account), provisions a VM, and once it is ready the tester opens a link and signs in with their own Forge account. No SSH keys, no extra setup on their side. This replaces the earlier plan in this issue, which still asked the tester to upload an SSH key before provisioning.

Target flow:

  1. Admin adds the tester. Two paths: create a brand new Forge account (temporary password, must be changed on first login), or register an existing Forge account by username (no account is created, no password is touched, display name and email are pulled from Forge).
  2. Admin provisions a VM. Provisioning no longer requires or reads any SSH key from the tester. The VM still receives the installer key and the workspace admin keys so we can manage and support it. The tester is added to that VM's access allowlist automatically.
  3. Once provision and install report ready, the tester receives the cockpit link (manually for now, automatically once the welcome email lands, see #236). They open it, sign in through their Forge account over single sign-on, and land in the cockpit.
  4. The AI provider keys (OpenRouter, Kimi) are preloaded into the VM by the deployer, so the assistant and apps work immediately. The tester never sees the raw keys: the settings page shows only a masked preview, and because testers have no shell on the VM there is no way to read the stored values.

Work items:

  1. Remove the tester SSH key requirement from provisioning. Stop reading and injecting the tester's Forge SSH keys. Keep injecting the installer and admin keys. Remove the upload-an-SSH-key step from the user-facing next steps and the admin warning that blocks provisioning when the key count is zero.
  2. Add an add-existing-user path so an existing Forge account is registered in the deployer database. The backend already detects an existing user and returns it without creating or modifying the account; the gap is that the row is only written on the new-account branch, so an existing user is never registered and cannot be provisioned. Add the registration plus a matching admin form, kept visually distinct from create-user so an operator does not make a duplicate.
  3. When a signed-in Forge user is not on a tester's allowlist, return a friendly styled page that explains they are not authorized for this sandbox and to contact the admin, instead of the current plain not-in-allowlist text. Tracked at lhumina_code/hero_proxy#57.

Security note: reusing an existing Forge account is safe for sign-in. The login uses the read:user scope only, so the token the proxy stores on the user's behalf can read their profile but cannot read private repositories or act on their account. Keep the scope at read:user. Dropping tester SSH keys also makes the preloaded provider keys unreadable to testers in every case, because there is no tester-controlled shell on the VM.

Acceptance: register an existing Forge user who has no SSH key, provision and install, confirm they open the link, sign in with their own Forge credentials, reach the demo apps, and that the assistant works with the preloaded keys. Confirm a non-allowed Forge user gets the friendly page rather than the raw error.

Goal: make onboarding a tester as simple as possible for non-technical people. An admin adds a tester (new or existing Forge account), provisions a VM, and once it is ready the tester opens a link and signs in with their own Forge account. No SSH keys, no extra setup on their side. This replaces the earlier plan in this issue, which still asked the tester to upload an SSH key before provisioning. Target flow: 1. Admin adds the tester. Two paths: create a brand new Forge account (temporary password, must be changed on first login), or register an existing Forge account by username (no account is created, no password is touched, display name and email are pulled from Forge). 2. Admin provisions a VM. Provisioning no longer requires or reads any SSH key from the tester. The VM still receives the installer key and the workspace admin keys so we can manage and support it. The tester is added to that VM's access allowlist automatically. 3. Once provision and install report ready, the tester receives the cockpit link (manually for now, automatically once the welcome email lands, see https://forge.ourworld.tf/lhumina_code/home/issues/236). They open it, sign in through their Forge account over single sign-on, and land in the cockpit. 4. The AI provider keys (OpenRouter, Kimi) are preloaded into the VM by the deployer, so the assistant and apps work immediately. The tester never sees the raw keys: the settings page shows only a masked preview, and because testers have no shell on the VM there is no way to read the stored values. Work items: 1. Remove the tester SSH key requirement from provisioning. Stop reading and injecting the tester's Forge SSH keys. Keep injecting the installer and admin keys. Remove the upload-an-SSH-key step from the user-facing next steps and the admin warning that blocks provisioning when the key count is zero. 2. Add an add-existing-user path so an existing Forge account is registered in the deployer database. The backend already detects an existing user and returns it without creating or modifying the account; the gap is that the row is only written on the new-account branch, so an existing user is never registered and cannot be provisioned. Add the registration plus a matching admin form, kept visually distinct from create-user so an operator does not make a duplicate. 3. When a signed-in Forge user is not on a tester's allowlist, return a friendly styled page that explains they are not authorized for this sandbox and to contact the admin, instead of the current plain not-in-allowlist text. Tracked at https://forge.ourworld.tf/lhumina_code/hero_proxy/issues/57. Security note: reusing an existing Forge account is safe for sign-in. The login uses the read:user scope only, so the token the proxy stores on the user's behalf can read their profile but cannot read private repositories or act on their account. Keep the scope at read:user. Dropping tester SSH keys also makes the preloaded provider keys unreadable to testers in every case, because there is no tester-controlled shell on the VM. Acceptance: register an existing Forge user who has no SSH key, provision and install, confirm they open the link, sign in with their own Forge credentials, reach the demo apps, and that the assistant works with the preloaded keys. Confirm a non-allowed Forge user gets the friendly page rather than the raw error.
mik-tf commented 2026-06-04 01:26:57 +00:00
Author
Owner
Copy link

Deferring this for now; it is not part of the current short plan. We are prioritizing onboarding through brand-new accounts rather than inviting people on their existing forge.ourworld.tf accounts. A fresh account is safer because it only carries the access we grant it for the sandbox, whereas reusing an existing account would inherit whatever repository and organization access that person already has. We can revisit inviting existing users later if there is demand.

Signed-by: mik-tf mik-tf@noreply.invalid

Deferring this for now; it is not part of the current short plan. We are prioritizing onboarding through brand-new accounts rather than inviting people on their existing forge.ourworld.tf accounts. A fresh account is safer because it only carries the access we grant it for the sandbox, whereas reusing an existing account would inherit whatever repository and organization access that person already has. We can revisit inviting existing users later if there is demand. Signed-by: mik-tf <mik-tf@noreply.invalid>
mik-tf changed title from Onboard existing forge.ourworld.tf users as testers (invite, do not create) to Simplify tester onboarding: reuse existing Forge users, drop tester SSH keys, clearer access errors 2026-06-05 12:22:25 +00:00
mik-tf commented 2026-06-05 16:24:35 +00:00
Author
Owner
Copy link

Done and proven live. The simpler onboarding is shipped: a tester no longer needs an SSH key, an existing Forge account can be registered and reused, and there is a friendly access-denied page. We onboarded a first real existing user end to end on the live admin machine (register, provision, install, sign in with their own account) with no manual fixing. A follow-on to make this even simpler, doing add plus provision plus install in a single click while keeping the per-step buttons, is tracked at #255 . The welcome email (#236) is the next step.

Signed-by: mik-tf mik-tf@noreply.invalid

Done and proven live. The simpler onboarding is shipped: a tester no longer needs an SSH key, an existing Forge account can be registered and reused, and there is a friendly access-denied page. We onboarded a first real existing user end to end on the live admin machine (register, provision, install, sign in with their own account) with no manual fixing. A follow-on to make this even simpler, doing add plus provision plus install in a single click while keeping the per-step buttons, is tracked at https://forge.ourworld.tf/lhumina_code/home/issues/255 . The welcome email (https://forge.ourworld.tf/lhumina_code/home/issues/236) is the next step. Signed-by: mik-tf <mik-tf@noreply.invalid>
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
main
No results found.
Labels
Clear labels   
meeting-notes

Meeting notes and follow-ups

  
meeting-transcript

Raw meeting transcript; AI drafts the report

No labels
meeting-notes
meeting-transcript
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/home#247
No description provided.