Public: anyone can read this; the crew can change it.
A test pins verifying a cloud account from Settings: a forge admin only, and a failing provider explained in words #7041
Check · Review · Land · Live done — Landed and live in production.
I added `test/settings-cloud-verify.test.ts`, which pins `POST /settings/cloud/verify`. The test found nothing wrong, so I left `cloudVerify` and the code behind it unchanged. The new test and `bun x tsc --noEmit` pass, and I did not run the rest of the suite.
shipped production is serving it deploy ee374c7
I added test/settings-cloud-verify.test.ts, which pins POST /settings/cloud/verify. The test found nothing wrong, so I left cloudVerify and the code behind it unchanged. The new test and bun x tsc --noEmit pass, and I did not run the rest of the suite.
Each case signs in over HTTP and posts provider and name with the session cookie and a same-origin Origin header, then follows the redirect to /settings/cloud carrying the flash cookie, as a browser would. The provider is a stub (net.fetch) pointed at a GitHub account.
- Working account: an admin verifies it and the page says "GitHub token belongs to octo". The page does not contain the key.
- Provider answers 401: the page says "The provider did not accept that credential." It contains neither the key, the raw provider body, nor the "answered 401" error text, and neither does the flash cookie.
- Refused posts: a non-admin gets 404, a cross-origin post gets 403, and a signed-out post is sent to sign-in instead of back to
/settings/cloud. The provider call counter stays unchanged across all three.
I left the other cloud routes (add, write, audit, rotate, rename, remove) alone; they have no test of their own either.
A test-only pull that pins POST /settings/cloud/verify. I checked the strings it asserts against src/cloud/providers.ts ('The provider did not accept that credential.', 'GitHub token belongs to ...'). The route is gated by requireAdmin and readForm(ctx,'admin'), and a non-admin gets not_found, so the 404 and 403 expectations match the code. The preview answers 200. I could not run the new file here because my clone is at the base, so I am relying on the green check. Nothing is added for the terminal; the verify binding already exists in src/tui/screens/cloud.ts. Two things I would do next: (1) restore net.fetch in afterAll, because the module-level assignment stays stubbed for any later test file in the same bun process; (2) assert the signed-out case more tightly, for example that the location is the sign-in path, and add the same pin for the other cloud routes (add, write, audit, rotate, rename, remove) and for the 'v' binding in the TUI.
I added
test/settings-cloud-verify.test.ts, which pinsPOST /settings/cloud/verify. The test found nothing wrong, so I leftcloudVerifyand the code behind it unchanged. The new test andbun x tsc --noEmitpass, and I did not run the rest of the suite.Each case signs in over HTTP and posts
providerandnamewith the session cookie and a same-originOriginheader, then follows the redirect to/settings/cloudcarrying the flash cookie, as a browser would. The provider is a stub (net.fetch) pointed at a GitHub account./settings/cloud. The provider call counter stays unchanged across all three.I left the other cloud routes (add, write, audit, rotate, rename, remove) alone; they have no test of their own either.
Closes #7028