Repository navigation
feat(auth): let parents manage single-use registration keys - #73
Merged
Merged
Conversation
added 4 commits
November 5, 2026 15:31
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
改了什么、为什么
Verified parents can generate, copy, inspect and revoke a single-use child registration KEY from
/family. Password login or reauthentication within five minutes is required for writes; reauthentication rotates the session/CSRF token without extending its absolute expiry. Keys contain 80 random bits, expire after 24 hours, and are stored only as SHA-256 hashes. Raw text is returned only by generation and kept in page memory.A family-scoped transaction and partial unique index serialize replacement and enforce one unused, unrevoked KEY. Shared PostgreSQL quotas allow five generations/hour and twenty/day. The same transaction rechecks session validity, verification, credentials and family epoch; password recovery also invalidates unused keys. Child redemption remains #24.
Closes #23
Testing(怎么测的)
npm run check: formatting, lint, architecture, TS7, 86 API tests, 13 web tests, 23 toolchain/workflow tests, application and Storybook builds pass.npm run test:db: 49 tests pass on isolated PostgreSQL 17, including concurrent replacement, quotas, family isolation, exact TTL, legacy sessions requiring reauthentication, rotation, recovery races and RLS.npm run test:e2e: 24 desktop/mobile flows pass against the real local API/database. Copying is also covered by a web interaction test.npm run test:accounts: six portable Compose tests pass, covering repeatable migrations, TLS/CA packaging, readiness, two-instance accounts/shared limits, and database outage/recovery.npm run test:staging: 36 tests pass. Schema generation reports no drift; duplication is 0.56% against the existing 2% limit;git diff --checkpasses.Synthetic local Chromium screenshots: before, after, phone, reauthentication. These are visual review artifacts, not a pixel-regression baseline or staging acceptance. Staging release 42059584565 passed after exact-main CI 42059964561. Provider readback confirms education-access-spike.hyp.app points to READY deployment dpl_CdMW66F4DAVbHmzFvUGM2HW7BddJ, revision 1c1fab5, region sin1. Maintainer confirmed all requested browser checks passed: generation/copy, refresh hiding raw text while preserving status, regeneration and revocation; mainland access and latency targets are not inferred from local tests.
Risk(风险)
High: identity authorization, shared contracts and additive database migration. Migration 0005 adds recent-password timestamps, KEY lifecycle metadata, a generation-budget table and a partial unique index. Duplicate unused legacy keys are revoked except the latest by expiry before creating the index. Existing sessions stay logged in but require password confirmation for KEY management. New tables receive staging RLS/privilege hardening. No new secrets, provider changes or production deployment; existing Singapore staging configuration is retained.
How to revert(坏了怎么撤回)
Revert the PR and release the previous application through the guarded staging process. Retain the additive columns, budget table and index; do not run a destructive down migration. Prior account/session behavior remains supported, while the previous build has no KEY-management interface. Revoked keys must remain revoked; lost raw keys require regeneration. See docs/evidence/23/README.md for scope and verification boundaries.
检查清单
human-reviewed标签