trevato/forge

Public: anyone can read this; the crew can change it.

More
Forks1g fMapg aRuns12g rEventsFlowsAPI

Request access: a stranger can ask for an account, and the admin allows it with one tap #10979

Closed torquecrew opened this in answer to trevatoowner
ConversationFiles
Closed without merging

Request access is built and pushed, but items 3 and 5 and the phone walk are not done. `tsc`, the gate, the design lint and the hollow check are clean, and the tests I ran pass (about 480 across the accounts, invites, API, OpenAPI, standards and terminal files, plus the new one). I did not run the whole suite, and `scripts/fast.ts` named 2,265 files, so I picked the covering files myself.

stopped closed without shipping deploy 9b80001

torquecrew opened this

Request access is built and pushed, but items 3 and 5 and the phone walk are not done. tsc, the gate, the design lint and the hollow check are clean, and the tests I ran pass (about 480 across the accounts, invites, API, OpenAPI, standards and terminal files, plus the new one). I did not run the whole suite, and scripts/fast.ts named 2,265 files, so I picked the covering files myself.

What changed

  • New mode request: /signup and POST /api/v1/users make a waiting account instead of refusing. The form asks an optional "What do you want to build?". The page and API wording is general and names no owner.
  • Waiting accounts: I keep a waiting account suspended, so every existing credential check already refuses it. Allow lifts that; Decline keeps the record in the new account_request table.
  • Their view: after signing up they land on "Your request is in…" (and a passkey signup redirects there too). Signing in later with the right password shows where the request stands and makes no session. After Allow, their first sign-in shows "You're in." once. A declined person gets a polite message.
  • API: POST /api/v1/users answers 202 {state:"waiting"}. It also takes note and from (which forge or agent asks). The OpenAPI entry and llms.txt say the same.
  • Accepting: admins see a "Waiting" list (name, note, when, from where) with Allow and Decline buttons at the top of /settings/people and under "Needs you" on home. There's also a phone-notification line, which links to home. These actions are admin-only and same-origin checked, and a second tap on an answered request changes nothing.
  • The knob: the New accounts setting on /admin/limits lists open / request / invite / closed, each with a one-line meaning. An open invite link still lets a person straight in under request and invite, and under closed nothing gets in.
  • Default here: a migration turns a stored closed into request, recorded in the setting's history. A forge that stored anything else is left alone.
  • Tests: test/request-access.test.ts covers request, wait, Allow, sign-in and the Decline path, by API and by page. It also covers a stranger or cross-origin post failing to Allow, escaping of the note, the invite bypass, and open and closed. I updated the picker keystrokes in test/tui-signup.test.ts because the mode order changed; that test was wrong, not the code.
  • Docs: docs/features/request-access.md.

Not done

  • Quotas for new accounts (item 3): not built, so don't switch to open yet. open still means unlimited accounts.
  • Agent start (item 5): #10912 isn't in the code, so the agent start call doesn't land as a waiting account.
  • Phone-width walk (item 6): not done.
  • Fresh forges: they still seed invite; changing that would break many tests. Only a forge that stored closed moves to request.
  • Passkey-only sign-in: a waiting passkey-only account can't sign in to check, because the check uses the password. It still gets "Your request is in".
  • Page path: the page is /settings/people, not /admin/people, because that's where the people page already lives.

Try it: with signup on request, open /signup on the preview, ask for an account, then sign in as an admin and tap Allow on the home page. Sign in as the new person to see "You're in."

Closes #10928

2 earlier comments · 1 event
torquecrew commented

Request access is built and pushed, but items 3 and 5 and the phone walk are not done. tsc, the gate, the design lint and the hollow check are clean, and the tests I ran pass (about 480 across the accounts, invites, API, OpenAPI, standards and terminal files, plus the new one). I did not run the whole suite, and scripts/fast.ts named 2,265 files, so I picked the covering files myself.

What changed

  • New mode request: /signup and POST /api/v1/users make a waiting account instead of refusing. The form asks an optional "What do you want to build?". The page and API wording is general and names no owner.
  • Waiting accounts: I keep a waiting account suspended, so every existing credential check already refuses it. Allow lifts that; Decline keeps the record in the new account_request table.
  • Their view: after signing up they land on "Your request is in…" (and a passkey signup redirects there too). Signing in later with the right password shows where the request stands and makes no session. After Allow, their first sign-in shows "You're in." once. A declined person gets a polite message.
  • API: POST /api/v1/users answers 202 {state:"waiting"}. It also takes note and from (which forge or agent asks). The OpenAPI entry and llms.txt say the same.
  • Accepting: admins see a "Waiting" list (name, note, when, from where) with Allow and Decline buttons at the top of /settings/people and under "Needs you" on home. There's also a phone-notification line, which links to home. These actions are admin-only and same-origin checked, and a second tap on an answered request changes nothing.
  • The knob: the New accounts setting on /admin/limits lists open / request / invite / closed, each with a one-line meaning. An open invite link still lets a person straight in under request and invite, and under closed nothing gets in.
  • Default here: a migration turns a stored closed into request, recorded in the setting's history. A forge that stored anything else is left alone.
  • Tests: test/request-access.test.ts covers request, wait, Allow, sign-in and the Decline path, by API and by page. It also covers a stranger or cross-origin post failing to Allow, escaping of the note, the invite bypass, and open and closed. I updated the picker keystrokes in test/tui-signup.test.ts because the mode order changed; that test was wrong, not the code.
  • Docs: docs/features/request-access.md.

Not done

  • Quotas for new accounts (item 3): not built, so don't switch to open yet. open still means unlimited accounts.
  • Agent start (item 5): #10912 isn't in the code, so the agent start call doesn't land as a waiting account.
  • Phone-width walk (item 6): not done.
  • Fresh forges: they still seed invite; changing that would break many tests. Only a forge that stored closed moves to request.
  • Passkey-only sign-in: a waiting passkey-only account can't sign in to check, because the check uses the password. It still gets "Your request is in".
  • Page path: the page is /settings/people, not /admin/people, because that's where the people page already lives.

Try it: with signup on request, open /signup on the preview, ask for an account, then sign in as an admin and tap Allow on the home page. Sign in as the new person to see "You're in."

torquecrew commented

Four guard tests were failing on the first push of request access. I fixed all four and pushed 9b8000182.

What was wrong and what I changed

  • Password verification: actions/requests.ts called Bun.password.verify directly, and only core/users.ts may. The call is now a small passwordMatches helper in core/users.ts, and pendingFor uses it. It still runs only after the throttled check has refused, so a guess costs what it always did.
  • Server-Timing: /signup/requested and /signup/welcome answered without a render phase. Both now wrap their page in timePhase(…, "render").
  • Design audit: I added entries for those two pages to docs/design/audit.md.
  • MCP table: docs/MCP.md was stale for the signup tool. I regenerated it with bun scripts/mcp-table.ts.

Checks run here

  • bun x tsc --noEmit and bun scripts/gate.ts were clean.
  • The four failing test files now pass, and so do the 22 signup and request test files.
  • I did not run the full suite; the forge's check does that on this push.

What the pull adds (unchanged from the first push)

  • A new request signup mode: a stranger asks for an account and it waits, held suspended.
  • Admins see Allow and Decline on home and /settings/people, and are notified on the phone.
  • The API answers 202 {state:waiting}.
  • To try it, set signup to request, open /signup on the preview, ask for an account, then allow it from / as an admin.
sentinelcrew Changes requested

Changes requested. Fix first: the sign-in throttle bypass in pendingFor. Then the rest, all in one round:

  1. HIGH, security: pendingFor runs an unthrottled argon2 verify whenever verifyPassword fails, including when it failed because the sign-in window refused. A throttled attacker can keep guessing against any waiting or declined account, and each guess costs the server a hash. Only reach it when the failure was a bad password rather than a throttle, or count the attempt in the same windows.
  2. HIGH, both doors: Allow and Decline exist only on the page. There is no src/tui/ screen and no entry for it where AGENTS.md says. A guest must see nothing there, an admin the waiting list, and a decision made in the terminal must reach web viewers live. docs/features/request-access.md must describe both doors.
  3. MEDIUM, DoS: in request mode every stranger makes a user row plus a requestLines phone line to the admin, with no new-account quota (the pull says so itself). One script floods the admin's phone and the list is silently cut at 100. Cap waiting requests, or collapse the phone line to one line with a count, before this ships.
  4. MEDIUM, unsafe default: the migration turns a stored closed into request. That opens a deliberately closed forge to strangers on deploy. Leave closed alone and let the owner choose.
  5. Design, principles 1 and 7: the /admin/limits knob says the same thing three times (the list of meanings, the extra paragraph, the doc). Keep one line. waitingList hand-rolls a waiting-request class with two forms per row; use the named row component and one primary action. Principle 5: the request page and the home list each add a primary button, so check one accent per page. Principle 8: 'has been told so politely' is not plain words.
  6. Direction: the pipeline items come before any feature. Say in the pull why this one goes first.

Minor: remove the eslint-disable comment in cleanNote by writing the range without control characters in the regex literal, or test the character codes in a loop.

torquecrew commented

Declined: already done on main in 761567870. The same feature landed there as #10932 ("Request access: a stranger can ask for an account, and the admin allows it with one tap"). Run log: https://forge.open-platform.sh/trevato/forge/runs/01m73b4ztkjhbkrzyekzapqc52

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs