fix(e2e): register disposable accounts through the signup bot guard (BUNYIP-384) #378

Merged

nrupard merged 1 commit from fix/BUNYIP-384-e2e-signup-guard into main

2026-07-18 16:47:46 +02:00

nrupard commented

2026-07-18 16:28:24 +02:00

Owner

Summary

Makes the E2E suite's disposable-account registration satisfy the BUNYIP-377 signup bot guard (enabled on c-01 staging). Fixes BUNYIP-384.

Root cause

The guard (empty honeypot + a timing signup_token from GET /v1/auth/register-challenge, submitted no sooner than SIGNUP_MIN_FILL_SECONDS = 2s) is enabled on c-01, where the deployed-instance E2E runs. registerDisposable POSTed /v1/auth/register with only {email, password}, so verify_signup_not_bot rejected it with the uniform 400 ("We couldn't complete your registration..."), failing the change-email / magic-link / password-reset specs. It surfaced on the BUNYIP-380 PR (#377) E2E run but is unrelated to that change.

Change

e2e/lib/accounts.ts registerDisposable now mirrors the real register form: GET /v1/auth/register-challenge -> read data.token -> wait ~2.1s (past the min-fill window) -> POST /v1/auth/register with signup_token and no contact_channel (empty honeypot). Added a registerChallenge route to e2e/lib/api.ts. When the guard is off (dev / prod) the extra token is ignored server-side, so the helper is uniform across environments.

Not touched

No server/guard change - the guard stays enabled and is now actually exercised on staging by the E2E.
signup.spec.ts registers via the real UI form (which already renders the honeypot + token) and is test.fixme, so it needs no change.

Test

npx tsc --noEmit clean. The guard flow end-to-end is validated by this PR's deployed-instance E2E run - the disposable-account specs should go green.

Note

This also unblocks BUNYIP-380 (#377): its red E2E was this same guard failure, not the SSE change. After this merges, re-run / rebase #377.

## Summary Makes the E2E suite's disposable-account registration satisfy the BUNYIP-377 signup bot guard (enabled on c-01 staging). Fixes BUNYIP-384. ## Root cause The guard (empty honeypot + a timing `signup_token` from `GET /v1/auth/register-challenge`, submitted no sooner than `SIGNUP_MIN_FILL_SECONDS` = 2s) is enabled on c-01, where the deployed-instance E2E runs. `registerDisposable` POSTed `/v1/auth/register` with only `{email, password}`, so `verify_signup_not_bot` rejected it with the uniform 400 ("We couldn't complete your registration..."), failing the change-email / magic-link / password-reset specs. It surfaced on the BUNYIP-380 PR (#377) E2E run but is unrelated to that change. ## Change `e2e/lib/accounts.ts` `registerDisposable` now mirrors the real register form: `GET /v1/auth/register-challenge` -> read `data.token` -> wait ~2.1s (past the min-fill window) -> `POST /v1/auth/register` with `signup_token` and no `contact_channel` (empty honeypot). Added a `registerChallenge` route to `e2e/lib/api.ts`. When the guard is off (dev / prod) the extra token is ignored server-side, so the helper is uniform across environments. ## Not touched - No server/guard change - the guard stays enabled and is now actually exercised on staging by the E2E. - `signup.spec.ts` registers via the real UI form (which already renders the honeypot + token) and is `test.fixme`, so it needs no change. ## Test `npx tsc --noEmit` clean. The guard flow end-to-end is validated by this PR's deployed-instance E2E run - the disposable-account specs should go green. ## Note This also unblocks BUNYIP-380 (#377): its red E2E was this same guard failure, not the SSE change. After this merges, re-run / rebase #377.

nrupard added 1 commit

2026-07-18 16:28:24 +02:00

fix(e2e): register disposable accounts through the signup bot guard (BUNYIP-384)

E2E / Playwright against deployment (pull_request) Successful in 30s

Details

Check / fmt + clippy + build + tests (pull_request) Successful in 19m17s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

c8877e6947

The BUNYIP-377 signup bot guard is enabled on c-01 (staging), where the deployed-instance E2E suite runs. `registerDisposable` POSTed /v1/auth/register with only {email, password}, so with the guard on `verify_signup_not_bot` rejected every disposable registration with the uniform 400 ("We couldn't complete your registration. Please reload the page and try again."), failing the change-email / magic-link / password-reset specs. It surfaced on an unrelated PR's E2E run.

Mirror the real register form: GET /v1/auth/register-challenge for the timing token, leave the honeypot (contact_channel) empty, wait past the 2s minimum-fill window, then POST with signup_token. When the guard is off (dev / prod) the extra token is ignored server-side, so the helper stays uniform across environments. The UI-driven signup.spec is unaffected - the rendered form already carries the fields - and needs no change.

tsc --noEmit clean; the guard flow itself is exercised by the deployed-instance E2E run.

#BUNYIP-384

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

nrupard scheduled this pull request to auto merge when all checks succeed

2026-07-18 16:29:56 +02:00