[dikshantgoyal011]

What this fixes

Fixes from a code review of #38 (sign-in and the waitlist), now on preview. Each commit is one area:

d013905 Sign-in limits and the request body (api)

• IPv6. The per-network limits (30 codes and 60 checks an hour) counted each IPv6 address on its own. A host usually holds a whole /64, so it could ask for codes from new addresses without ever reaching the limit, for example to email-bomb addresses through our Resend account. An IPv6 address is now counted by its /64.
• Codes not sent no longer use up the address's limit. If the email failed, or another request won the one-a-minute slot, the request still counted toward the address's 5 an hour, so a few failed sends could lock someone out for an hour. Those requests now give their count back.
• Request bodies are capped while they are read. A body sent without a Content-Length was read in full before its size was checked. It's now read in chunks and refused past 4 KB.
• No more flaky rate-limit tests. The service counts in fixed hourly and daily windows on the real clock, so a test that started just before the hour could fail. Those tests now wait for the next window when the current one is about to end.

f4441a2 The admin page shows each account's real status (api, site)

• With SIGNUP_MODE set to "open", the admin page listed old waitlist accounts as Waiting, with Approve buttons, although the console already lets them in. They now show as approved. Their stored status is kept, so they wait again if the waitlist comes back.
• Approving an account that's already approved (two admins at once, or a second click) said the approval email could not be sent. It now answers alreadyApproved, and the page says "…was already approved, so no email was sent."

157687d A failed session check no longer signs people out (site)

• When the service couldn't be asked who is signed in (a network blip, or the service briefly down), the site treated it as signed out: /app, /account and /waitlist sent the reader to /login. Those pages now show "We couldn't check your sign-in." with Try again. "Check again" on the waitlist says the service can't be reached and stays on the page.

d02a0c2 Copy, a comment and the dev setup (site, api)

• /signup said you'd open the console straight away. It now says new accounts join the waitlist.
• The note in site/src/constants/links.ts on bringing back the Tally form named a check that Sign in with an emailed code, with a waitlist for the beta #38 had removed. It now says to restore that check too.
• api/.dev.vars.example allowed http://localhost:5173, where sign-in can't work, because the SameSite=Strict cookie lives on 127.0.0.1. The example and api/README.md now say to use 127.0.0.1.

After merging

The api/ changes in the first two commits take effect only once the Worker is redeployed (npm --prefix api run deploy, by someone with Cloudflare access). The site changes deploy with the preview workflow as usual.

Testing

• npm --prefix api run check: 57 tests, all passing. A new test covers IPv6 networks; others check that failed sends give their count back, the open-mode listing, and the already-approved answer. With the fixes undone, those tests fail.
• npm --prefix site run check passes at every commit, and docs/ matches a rebuild.
• In Edge against a local service:
  • sign-in: 25 checks
  • waitlist: 25 checks
  • the fixes: 15 checks, covering the service going down on /app, /account and /waitlist, Try again before and after it comes back, two admins approving the same account (one email, no false failure), and the sign-up copy
• The production build with its CSP, served as GitHub Pages serves it: 18 checks from the landing page's Join the waitlist through sign-up, approval and the console, with no CSP violations or console errors.

🤖 Generated with Claude Code