Review 5/5 — Core & security: issuance lifecycle, retention, auth, org admin

[ArneeMe]

Part 5 of the review-ordered stack (on develop). Everything that deserves deep human investigation, concentrated in one PR. Take your time here — the rest of the stack is rubber-stampable by comparison.

Issuance & data lifecycle (the privacy promise)

• Cert POST: idempotent per submission — inserts the certificate, or returns the existing one (alreadyIssued: true) if this submission already has a cert. Does not delete the submission. Records issued_by (the audit CLAUDE.md explicitly allows: who issued, when, no payload). GET lists issued certs (no hash exposed, but submissionId is — it's not personal data, and the dashboard needs it).
• Retention: lazy sweep wired into submissions GET/POST deletes rows older than 24h (SUBMISSION_TTL_HOURS, one constant) — this is the only deletion mechanism, regardless of whether a cert has been issued. That gives a regeneration window: "Generer PDF" can be re-run for the same submission any time before the sweep, e.g. to fix a lost or misprinted PDF. Dashboard shows the per-card countdown and an "Utstedt" chip on submissions that already have a cert (state seeded from the certificates GET, so it survives a reload).
• Dashboard issuance flow: PDF preview with FORHÅNDSVISNING watermark (renders real data, registers nothing), batch issuance → one ZIP, copy-verify-URL.

Revised per review feedback: the first draft of this PR deleted the submission in the same transaction as the cert insert, then a later PR in the original stack (retention model / 24h window) replaced that with the model described above. Shipping the wrong model first and superseding it three PRs later was backwards, so the regeneration-window model is now what #29 ships directly. The email notification to admins on new submissions (Resend-based, content-free) is dropped entirely — judged as unnecessary complexity; sendInviteEmail, which the invites feature below still needs, is untouched. Follow-up: the PR further up the stack that originally introduced this retention model is now redundant and will need reconciling (likely closed) when review reaches it — tracked, not touched yet.

Accounts & membership (the authz surface)

• Password reset (/login/glemt → /login/reset via Nhost), self-signup /registrer (a fresh account has zero memberships).
• Members API/UI: list/add/remove behind requireOrgMemberBySlug, last-member lockout guard.
• Invites: 7-day tokens; redemption requires the session email to match the invited address, so a leaked link alone grants nothing.
• Platform admin /admin: gated by the PLATFORM_ADMIN_EMAILS env allowlist (unset = surface disabled; checked server-side against auth.users, never client input); creates org + first member in one transaction. create-org.ts for CLI.
• Utstedte view (per-month/per-template counts), admin NO/EN language scaffolding.

Schema & docs

• 0000-baseline-schema.sql (full reproducible schema, IF NOT EXISTS — no-op on prod) + 2026-07-invites.sql + 2026-07-issued-by.sql. CLAUDE.md/README describe the regeneration-window model directly (not a since-superseded delete-at-issuance one).

Other changes made during review-stack sync

• Rate limiter dropped from the submissions POST (per review feedback, same cleanup already applied to the tooling and feedback PRs) — size/shape validation on the endpoint is untouched, only the per-IP throttle is gone.
• Rebase note: this PR's base was originally claude/review-4-feedback-branding. After Review 4/5 — Org branding on public pages #28 merged, its target wasn't develop directly, so I retargeted here and merged develop in. One conflict in the admin nav (layout.tsx): kept this PR's data-driven nav (adds Members + Issued links) but dropped the Tilbakemeldinger entry, since Review 4/5 — Org branding on public pages #28 removed that feature and its string key.

Deploy checklist (one-time)

1. Hasura console: run 2026-07-issued-by.sql and 2026-07-invites.sql, re-track certificates, track invites.
2. Nhost → Auth → Redirect URLs: add the production /login/reset.
3. Cloudflare env: PLATFORM_ADMIN_EMAILS (your email); optionally RESEND_API_KEY + NOTIFY_EMAIL_FROM (invite emails only now — see .env.example).
4. Live pass: reset email, signup, invite redeem, issue + verify one attest, confirm the submission is deleted within the 24h window.

Verification

Typecheck, lint, 119 unit tests, 10 E2E, production build (with placeholder env) — all green.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BFHkXUuHJME4cF9AJWbavB

[cloudflare-workers-and-pages]

Deploying inf319-certificate with    Cloudflare Pages

Latest commit:	8b690c1
Status:	✅  Deploy successful!
Preview URL:	https://c80d8246.inf319-certificate.pages.dev
Branch Preview URL:	https://claude-review-5-core-securit.inf319-certificate.pages.dev

View logs

[ArneeMe]

⚠️ Model change, decided after this PR was opened: the delete-submission-at-issuance behavior described here is superseded by #32 (stacked later in this chain). Issuing no longer deletes the submission; the 24h retention sweep is the sole deleter, the cert POST is idempotent per submission, and admins can regenerate the PDF within the window. Review the issuance lifecycle here together with #32's diff — the final merged state is #32's semantics.

---

Generated by Claude Code

[ArneeMe]

Security review notes (inline pass over every new attack surface in this stack — use as a checklist for your deep review):

Verified sound:

• Every org-scoped route calls requireOrgMemberBySlug; ids from the client get templateBelongsToOrg/submissionBelongsToOrg ownership checks; the feedback DELETE pins the org id from the membership check so cross-org deletion is impossible.
• All Hasura access uses GraphQL variables — no string interpolation into query documents anywhere.
• Platform admin: allowlist is env-only (not self-grantable through any app surface), the caller's email is read from auth.users server-side, unset env disables the surface entirely.
• Invite redemption requires session email == invited email (case-insensitive), so a leaked link alone grants nothing; tokens are unguessable UUIDs with 7-day expiry and single redemption.
• The branding endpoint exposes only org name + default logo (both already public on every issued PDF); no other asset kind reachable unauthenticated.
• The privacy model holds: no route logs or returns volunteer fields outside the transient submissions surface; notifications and feedback are content-free/anonymous by construction.

Two findings, fixed in #35:

1. Cert issuance idempotency was check-then-insert — a concurrent double-click could race past it. Now backed by a unique index on (organization_id, submission_id) with the violation handled as "already issued". (Duplicates were harmless — identical hash — but messy.)
2. Malformed invite tokens hit Hasura's uuid type validation and surfaced as 500s; now validated to a clean 404.

Accepted trade-offs (documented, not bugs): per-isolate best-effort rate limiting; members-remove lockout guard is check-then-delete (self-inflicted only, org can't reach zero members without racing yourself); admin emails visible to co-admins of the same org in the Utstedte view.

---

Generated by Claude Code